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CHAPTER 1: INTRODUCTION 

The National Software Works (NSW) is a significant development in 
the fields of distributed processing and network operating systems. 

Its initial ambitious goal was to link the resources of a set of 
geographically distributed and heterogeneous hosts with an operating 
system which would appear as a single entity to a user. 

The National Software Works has been developed in response to a 
growing concern over the high cost of software. The Air Force has 
estimated, for example, that by 1985 software expenditures will be 
over 90? of total computer system costs. In the attack on the cost and 
complexity of developing and maintaining software, both industry and 
government have made enormous investments in software tools -- 
automated aids for the implementors of software and for the managers of 
software projects. These tools include compilers, editors, debuggers, 
design systems, test management tools, etc. 

As a result of this investment, a large inventory of excellent 
tools has come into being, so that the difficulty confronting the 
management of a programming project lies not in the existence of 
suitable tools, but in their availability. If some essential tool does 
not happen to have a version which runs on a computer to which the 
project has access, the manager is forced to choose among the expensive 
alternatives of (1) foregoing use of the tool, (2) undertaking to 
acquire or produce a surrogate tool on his hardware, or (3) purchasing 
(access to) a computing system on which the tool does run. 

Alternative (1) — not using the tool -- has become prohibitively 
expensive as the size and complexity of programming projects has grown: 
most projects can hardly choose not to use a compiler, and this, for 
instance, may lead to choice of a sub-optimal programming language 
merely because a compiler for it is available. 

Alternative (2) amounts to the software portability problem. The 
computing field has been chipping away at this intractable problem for 
years, by encouraging the use of standard -- or at least popular -- 
programming languages, having compilers on many different computers. 
Lacking this facility, the project must invest effort at the beginning 
to re-program -- and debug -- the tools it needs before starting on its 
actual task. 

Alternative (3) has been attacked most effectively with 
networking. Indeed, it was the marked success of the Arpanet in 
providing programmers economical access to diverse computers which 
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provided the foundation on which the concept of a "National Software 
Works" was built. Instead of moving the software from host to host, 
let the programmer (and manager) use each software tool on whatever 
host it already occupios. 

We can say that NSW tries, in effect, to make Alternative (3) more 
attractive, by providing the Arpanet without some of its drawbacks. 
Using the Arpanet in straightforward fashion, by using Telnet and FTP 
to access hosts other than one's "home” system, does indeed give you a 
much wider domain of action, but nonetheless: 

o You need an account on eacn host. This involves the 
allocation of funding, drawing up contracts, etc. 

o The operating system on each host is different, so you must 
learn different login procedures, command languages, 
interrupt characters, file naming conventions, etc. Further, 
you must not confuse each system’s conventions as you move 
from tool tc tool . 

o Files output from one tool (say QEDX on MULTICS) are to be 
input to another tool (say CMS2M on IBM 360). This involves 
at least network transmission and usually file reformatting. 

To appreciate the magnitude of this problem one should try to 
use FTP (Arpanet File Transfer Protocol) to move a QEDX 
output file a sequential file of 9-bit ASCII characters in 
36-bit words -- to an IBM 360 to be a CMS2M input file — a 
blocked file of 80 EBCDIC character records in 32-bit words. 

These and similar problems will be familiar to anyone who has used 
several differe’^t systems. 

The purpose of NSW is to make this solution (of providing 
programmers access to tools on different hosts) a practical reality. 

The NSW user should not have to k'ow about 05/360, TENEX, and MULTICS 
with their differing file systems, login procedures, system commands, 
etc.; knowledge of how to use the individual tools which are needed for 
the job should suffice. He should not have to worry about reformatting 
and mcv-ng files from a 360 to a TENEX; file transmission should be 
completely transparent. The user should not have to worry about 
obtaining accounts on many different machines, but instead should have 
a single NSW account. 

Thus, the overall design goals of the National Software Works were 
to provide programmerr with a 
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0 Unified tool kit -- distributed over many hosts -- 

0 Single monitor with 

uniform command language, 
global file system, 

single access control, accounting, and auditing 
mechanism. 


and a 
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CHAPTER 2: HISTORY OF NSW PROJECT 

2.1 NSW Goals 

2.1.1 Original Directions 

As originally conceived, NSW was to provide a unified cross-net 
operating system of the kind described in the Introduction, and with 
the following specific external goals in mind: 

(1) The first such goal was large scale. 

Contemporary operating systems support tens of concurrent 
users; NSW was to support many more users, possibly as many as 
one thousand. The catalogue alone of the file system for that 
many users could easily fill a large disk pack. And the table 
space required for keeping track of a thousand users and the 
software tools they are using could easily exceed the virtual 
memory of TENEX. 

(2) The second goal was high reliability. 

If there are one thousand online users, then a two-hour system 
failure costs one man-year of work. The National Software 
Works -- particularly its monitor and file system -- must 
degrade gracefully. Failure of a single component -- e.g., a 
TENEX system on which tools are running -- must only reduce 
system capacity, not destroy it. Further, only those users 
actually using a failed component should be affected by its 
failure. 

(3) The third goal was support of project management. 

NSW was to provide to managers of software projects a 
collection of programs, called management tods, which they 
could use to monitor and control project activities. The 
underlying assumption here is that a manager's ability to 
insure that each programmer's efforts contribute most 
effectively to overall project goals can be greatly enhanced 
by automating routine management tasks. Furthermore, it is 
assumed that a good environment for this automation is the 
system which supports the project programming activities, 
because it represents an effective point for monitoring and 
controlling those activities. 
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(4) The fourth goal of NSW was practicality. 

NSW A'as not to be a "blue sky" system, whose implementation 

required unrealistic assumptions about its environment. In 

particular, "practicality" meant: 

o Minimum modifications to existing operating systems on 

Arpanet hosts. "Minimum" was, in fact, to be construed as 
"none". It was permissible, if necessary, to add 
privileged (i.e., non-user) code to existing systems, but 
the solution to the problem should not depend on rewriting 
the kernel of any existing operating system. 

o Minimum modifications to existing tools. Here, "minimum" 
no longer meant "none". It was permissible to require 
some change to a tool as part of the process of installing 
it in NSW, but such changes should be small-scale and 
straightforward. 

o Maximum generality. Any solution which permits the easy 
installation of existing tools must also allow the easy 
construction and installation of new tools. 

o No experimental hardware. This requirement meant that new 
hardware-oriented approaches to reliability -- e.g., 

PLURIBUS — could not be used. The NSW monitor and file 
system are to run on already available Arpanet hosts. 

Although it was never stated as explicitly as the goals enumerated 
above, it seemed to follow from the whole concept of a National 
Software Works that it would be the sole on-line working environment 
for most of its users. As we went about the initial design, our mental 
picture of the user's activity was that he would log into NSW and stay 
in that environment for all of his machine activity — cheerfully using 
any tool he had access to, without even knowing, or caring, on what 
host in the network it was running, or where his files were stored. 


2.1.2 Changed Directions 

As the initial design was completed and the prototype NSW was 
implemented and used, the original goals had to be somewhat modified. 

The original goal of supporting as many as one thousand users with 
a single NSW proved not to be economically feasible in tho present 
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state of the art: it would have required excessive hardware resources, 
and might still not have shown acceptable responsiveness. Hence, the 
current plan is to produce a self-contained, noderate-sized system -- 
supporting up to a hundred users -- which can be distributed in toto; 
that is, a number of such systems could be in operation independently 
on the same network. 

Given this reduction in scale, the projected implementation of a 
widely distributed, fully replicated, synchronized data base -- the 
design of which was well along -- was also seen as an inapppropriately 
large investment. If each NSW system then will have a single 
monitor host, the principal reliability issue becomes one of preventing 
a monitor-host crash from aborting ongoing tool operations. Thus, 
rather than casting the monitor as a set of cooperating distributed 
processes, as was designed in the large-scale reliability plan, we 
propose to allow tool execution to continue despite the absence of the 
monitor, given that the user's rights have initially been verified by 
the monitor, and by allowing the results of tool executions to be held 
indefinitely until the monitor is again available to accept delivery. 

Our mental picture of NSW utilization has also changed. At 
current hardware and network speeds, there is a human-time overhead to 
be paid for using NSW, and anyone with experience on a present-day 
timesharing system will be conscious of it. Use of a single tool is 
not too seriously degraded, compared to normal TIP-to-host operation, 
but inter-tool communication by passing files :hrough the central 
system seems to take a long time when compared with such operations 
within a single-host operating system. If the user does indeed have to 
use multiple tools at separate hosts, then using NSW is a pleasure in 
comparison with going through the scenarios necessary to perform the 
same operations using Telnet and FTP; but there doesn't appear to be a 
large market, as yet, for this ability. 

We believe, nonetheless, that there are at present valid uses for 
such a ’'Network ''jie-ating System" facility, and that there will be an 
even bigger place for it in the future, considering the forecasts of 
enormous interconnected networks of personal computers, mass stores, 
high-performance mainframes, and special-purpose devices; our future 
plans for NSW therefore include continued improvements in the facility 
for this mode of operation. 

U' wever, ou** ci'■rent' picture of the "heavy" user of NSW is that he 
will work, as he dcco now, p'-imarily within his "home" host system 
(though he might establish contact with it via NSW mechanisms), and he 
will use NSW facilities, when he needs to, on an escape basis -- he 
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will signal NSW that he has produced files to be placed in the NSW File 
System for others to access, or that he needs to execute some tool on a 
’’foreign" host. Later sections on the work of the Analysis Group will 
discuss the embodiment of this changed perspective. 

The design goals as stated in the Introduction, then, might be 
updated to say that the intent is to provide programmers -- and project 
managers -- with a wider and more automated environment, including: 

o Easy access to services not normally available on their home 
systems; 

0 Controlled access to a cross-net file system of text files, 
programs, and services; 

o A structure and some tools for project coordination and 
configuration management. 


2.2 NSW Architecture 

In this section, we summarize the overall structure of the NSW, as 
it evolved to meet the original design goals of a dispersed toolkit 
accessed through a central monitor. 


2.2.1 NSW Components 

The requirement is that many users on many different hosts be able 
to access many tools on many different hosts, under control of a 
central monitor, and with reference to a global file system. Analyzing 
this system according to the functions that must be available on each 
host, we were led to specify a number of functional processes, whose 
embodiments are called "NSW Components”. 

By its very definition, NSW is a distributed system. Tool 
processes run on different Arpanet hosts, and the monitor process must 
run en at least one Arpanet host; hence, there must be some form of 
inter-host process-to-process communication. There are low level 
Arpanet protocols for moving bits from host to host, and there are also 
several higher level protocols for moving files and for terminal 
communication. None of these protocols, however, is oriented toward 
the kind of inter-process communication which NSW requires. Moreover, 
even though NSW is being implemented on the Arpanet, we want to keep it 
as independent as possible of the underlying milieu. Network 
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technology is evolving, and we wish to be able to realize the NSW 
architecture on tomorrow's networks as well. Hence, the first 
technical problem to be solved is the definition and implementation of 
an appropriate inter-host inter-process communication protocol. The 
protocol developed for- NSW is called MSG, and the component on each 
host which implements the protocol is also called MSG. 

When the NSW user runs an interactive tool within NSW, either rJSW 
must arrange that his terminal appear to the tool as if it wer: a 
simple user terminal on the native host -- this is miost approp: iate 
when adapting existing tool programs to run within NSW -- or the tc.;l 
must be able to perform its input/output transactions via he HSG 
protocol. As well as talking to tools, the user will be giving 
commands directly to the NSW monitor, and it is rot feasible ''ci a. 1 
NSW users to have direct terminal access to the monitor host. 

Therefore, the user will be represented within the NSW system by a 
process (on any host, in principle) which will communicate for him with 
the monitor via MSG, and which will handle his conn^cticris to too-s. 
This component is called the Front End. 

A tool running on some machine makes system calls requesting 
resources — primarily file access. Since access to NSW syster, 
resources is to be controlled, accounted for, sna audited by tie NSW 
monitor, such requests must be diverted from the local system and 
referred instead to the NSW monitor. In addition, if the tool is 
interactive, it expects to have a terminal for communication with the 
user, and this in NSW is via the Front End. So, without modifying the 
operating system, we must divert the tool's communications with the 
user and the tool's requests for NSW resources, while still al'owing 
the tool to obtain local-service access of other kinds. The NSW 
component which solves this problem is called the Foreman. 

Batch tools are best described as those whose inpjt a ..utnit 
be completely specified before tool ;,xeGu..io<i begins. GuC’ i '1.' 
should not (and often cannot) be supe'-vlsed fro.'n a t-'.’ a . \ i 

the central monitor works together with a component Cdilel ' ^ ■ 1 

Job Package, running on the same host as the batch tool, to >u.p. ''■e 

execution of such "absentee" ccmputations, 

It was understood from the beginning that there would lu' 
physically separate NSW file-storage m-aia -- NSW jiles ohyoicall^ 
reside within che filing systems of uh. p.>. tic-ipdt,ir.g host.s, lot.-i'.y 'n 
(or "near") the hosts on which they .■ .t likely t.. he needt'.. 

Hence, there is need for a process coc-- type .-"f hcrt which 
understands that host's file syst-’-r, and rm^n ge v' e portion of th« 
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host system which is available for NSW file storage. Also, we expect 
that the output of one tool will be used as input to another tool. 
Unfortunately, if the first tool is a MULTICS editor and the second an 
IBM 360 compiler, this operation involves character translation (ASCII 
to EBCDIC), file reformatting (sequential file to blocked record 
file), and file movement (across the Arpanet). To handle these 
functions of file storage, transformation, and movement, there is 
an NSW component called the File Package. 

It is worth noting at this point that all of the above components 
are distributed. Every host in NSW has an MSG server process. Every 
site to which a user is connected has a Front End. Every tool-bearing 
host has a Foreman. Every host on which NSW files are stored has a 
File Package. It is also worth noting that implementation details of 
these components vary from host to host. A MULTICS Foreman will be 
vastly different from an IBM 360 Foreman. Functional specifications 
for these components are fixed throughout NSW, but implementation and 
optimization decisions are left free. 

And finally, there must be a component for the NSW monitor, or at 
least for those normal monitor functions which are not already 
performed by the Foreman (service calls for file access) or the Front 
End (terminal handling, command interpretation). This component is 
named the "Works Manager"; we shall discuss it in more detail in the 
next subsection. 

Let us then summarize the major functional areas of the NSW design 
and the components which embody those functions: 

0 Inter-host inter-process communication MSG 

o User interface Front End 

0 Diversion of communication with local 

operating system Foreman 

0 Supervision of batch jobs Batch Job Package 

0 File storage, transformation, and movement File Package 

c Monitor functions Works Manager 


2.2.2 NSW Monitor and File System 
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NSW Final Report for the Period Ending December 1980 


The design of the NSW Monitor — called the Works Manager -- was 
probably more affected than any other component by the goals of NSW. 
Functionally it is net different from any other conventional 
access-checking, resource-granting monitor (though the mechanisms for 
defining access domains are unusual). Structurally, however, it is 
significantly different. 

The goals of providing both large scale and reliability on 
conventioiial hardware led to a design for distributing the Works 
Manager and file system. If there are many instances of the NSW 
monitor on many different hosts, then failure of a host is not 
catastrophic. Unfortunately, distribution runs counter to the 
problem-required logical unity of the monitor and file system. If a 
user inserts a file into the file system using one tool and one 
instance of the file system, and then requests the same file using a 
different tool and a different instance of the file system, the two 
instances of the file system must share a common file catalogue for the 
system to behave properly. Similarly, all instances of the monitor 
"ust share an access-rights data base for proper validation of user 
requests to run tool?.. 

As mentioned in section 2.1.2, this ambitious design has been 

A "large" NSW system — with multiple Works Managers -- is 
still feasible, but with a partitioned (rather than a replicated) data 
base: each Works Manager will control the resources in that piece of 

the partitioned data base which it "owns", but will have to negotiate 
with another Works Manager that "owns" other resources. This strategy 
requires minimum synchronization while providing advantages in 
reli.abillty and robustness. 


2 3 Phase.? of NSW Development 

The design and implementation of the National Software Works ha.s 
proceeded in five slightly overlappig phases; 

o Structural design and feasibility demonstration 

o Detailed component design 

o Prototype implementation 

c Heliabjlicy and pet I'ortnsnce improvement 
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o Management Plan and Production System 
In the following subsections we describe these phases in more detail. 


2.3.1 Structural Design and Feasibility Demonstration 

The first phase of NSW development began in July 197^1 and 
concluded in November 1975. During this period, the basic architecture 
of NSW (described in Section 2.2) was established. Further, relatively 
ad hoc implementations of major components were made. These components 
were integrated into a system which was demonstrated to ARPA and Air 
Force personnel at Gunter AFB in November 1975. This demonstration 
exhibited various system functions, the use of batch tools on the IBM 
360 and Burroughs B4700, the use of interactive tools on TENEX, 
transparent file motion and translation, and a primitive set of project 
management functions. 

This demonstration confirmed that the expected NSW facilities 
could be implemented and that transparent use of a distributed tool kit 
was feasible. The NSW System, however, was inefficient and fragile. 
Further, many of the ad hoc implementations had design weaknesses which 
limited their general application to a sufficiently broad range of 
hosts and capabilities. For these reasons, an effort was begun to 
produce adequate component designs. 


2.3.2 Detailed Component Design 

This second phase of NSW development was begun in June 1975 with 
the initial MSG design document. Specifications were developed for 
Tool-Bearing Host components -- MSG, Foreman, and File Package. All of 
these specification documents were completed by March 1976. (They have 
all been revised since then, but the original specifications are still 
substantially correct.) 

During the same period, the external specification of the Works 
Manager was also produced. Again, although this specification has 
subsequently been revised, it is still substantially correct. The 
remaining portions of the core of NSW -- i.e., the batch tool facility, 
consisting of the Works Manager Operator, Interactive Batch Specifier, 
and Interface Protocol — were designed during phase one, and those 
designs were retained until phase four (see below). 
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The remaining major NSW component, the Front End, was the subject 
of several design efforts. Three incomplete specification documents 
were produced but none of these was wholly satisfactory. Nevertheless, 
sufficient design to allow implementation of a functionally correct 
Front End was accomplished. 


2 . 3.3 Prototype Implementation 

As specification documents were completed, various contractors 
began implementation of the NSW components on the initial set of hosts 
-- TENEX, MULTICS, and IBM 360; these efforts commenced in January 

1976. Implementation on TENEX proceeded more quickly than the effc ts 
on the other hosts — primarily because the MSG system designers were 
also TENEX implementors. By October 1976 prototype implementations 
which conformed to the published specifications had been made for all 
TENEX TBH components. In addition, all components of the core sysr,em 
were available on TENEX. 

Implementation of TBH components on MULTICS and IBM 360 proceeded 
more slowly; however, initial implementations of MSG components on both 
of these hosts were completed by the end of 1976. By November 1976 
sufficient progress had been made on implementation of a File Package 
and Foreman on MULTICS that it was possible to demonstrate an 
interactive tool running on MULTICS. Progress on implementation of 360 
(interactive) TBH components reached a similar position in September 

1977. 


Also during this phase, a TENEX Front End which functionally 
supported the Works Manager and Foreman according to the appropriate 
specifications was implemented. 

An NSW system containing prototype implementations according to 
the specifications of the core system, TENEX TBH components, TENF^ 
Front End, batch IBM 360 tools, as well as a rudirnrfjr fr / 
interactive tool was demonstrated to Air Force and ARPA peiscnnel 1n 
November 1976. At the same time, a demonstration of MSG components on 
all three hosts was also given. 


2. 3 .'I Reliability and Performance Improvement 

Even though implementation of components on MULTIoS and IBM 360 
was lagging, implementation of the core system, TENEX TBH components, 
and TENEX Front End had proceeded to the point that the issues of 
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reliability and performance assumed major importance. The system 
exhibited sufficient functional capability that it could clearly 
support use by programmers if it were sufficiently robust and 
responsive• 

The first task attacked was to provide robustness. Work had begun 
in 1975 on a full-scale NSW Reliability Plan -- this was the design for 
multiple Works Managers with duplicate data bases. This detailed Plan 
was released in January 1977. Since it was clear that implementation 
of the full Plan was a major undertaking, a less ambitious Interim 
Reliability Plan which ensured against loss of a user's files was begun 
in mid-1976. This Plan was also released in January 1977. By June 
1977 the core system, TENEX Foreman, and TENEX Front End had been 
modified to incorporate the features of that Interim Plan. In 
addition, both the MULTICS and IBM 360 Foremen (only partially 
implemented) were' altered to conform externally to the scenarios 
specified by the Interim Reliability Plan. A system exhibiting the new 
scenarios was released for use in June 1977. 

Performance of NSW had been slow from the initial implementation. 
The reasons for slow response were many: 

o Interaction between components was by a thin wire (MSG and 
the Arpanet). 

o NSW components (which constitute an operating system) 

nevertheless were executed as user processes under the local 
host operating system. 

0 Component implementation had been oriented towards ease of 
debugging and other concerns of prototype systems rather than 
towards the performance expected of a production system. 

In 1977, efforts to improve NSW performance were begun. 

The first effort was the development of a performance measuring 
package for TENEX MSG. Results of the first set of measurements were 
reported in April 1977; and a number of more sophisticated measuring 
packages were complete by February 1978. By May 1978, all TENEX 
components had been instrumented and measurements of page use, CPU 
time, elapsed time, use of JSYSes (TENEX monitor calls), etc., had been 
taken under a variety of system load conditions and on several 
different TENEX hosts. Efforts were then undertaken to make the 
performance improvements suggested by these measurements. 
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Performance improvement is an ongoing concern. Efforts to improve 
the program efficiency of TENEX components are substantially complete, 
but there are now plans for re-allocating some of the system functions, 
with the aim of making whole protocols more efficient. 


2 . 3.5 Production System 

Concurrent with the effort to improve NSW reliability and 
performance, an effort to make NSW a more packaged product were begun. 
Regression tests for the externally available NSW user system were 
developed and applied to each system release. A user's manual for the 
system was published. Documentation of the core system was produced. 
Finally, a draft configuration management plan was developed. 

Work was begun in late 1978 to establish NSW as a software 
product. The NSW Management Plan was generated. This document 
identified a number of roles associated with development, operation, 
and support of NSW as a product. Briefly these are as follows: 


Role 

Responsibilities 

Organization 

(PG) 

Policy Group 

Requirements and Policy 

RADC/ARPA 

(PDC) 

Product Development 

Product Definition 

GSG 

(OPS) 

NSW Operations 

Operations; User Support 

GSG 

(ACC) 

Architecture Control 

Product Integration 

COMPASS 

(DMC) 

Development and 
Maintenance 

Component Development 
and Maintenance 

BBN, COMPASS, 
HIS, UCLA 

(TM) 

Tool Manager 

Tool Management 

IITRI 


A product baseline is being established to bring NSW under 
Configuration Management. A reasonably complete set of 
requireirents/specification documents has been installed as a set of 
files in the NSW User System. NSW's Information Retrieval System 
allows queries on sets of documents; the naming scheme for the baseline 
demonstrates some of the power of NSW's file naming capabilities: 


Dc.. rrent Type 


Name Syntax 
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Requirements 

A-level 

Specifications 


NSW.REQUIREMENTS. . . 
NSW.A-SPEC. .. 


B-level NSW.B-SPEC.<component>. . . 

Specifications 
for <component> 


C-level NSW.C-SPEC.<operating-system>.<component>... 

Specifications 
for <component> 
on <operating-system> 


where the variables take on values as follows: 
<component> <operating-system> 


BJP 

TENEX 

FE 

OS360 

FL 

MULTICS 

FM 

UNIX 

FP 

• • • 


The revision level of all of these documents is also noted, as part of 
the file name. 

A computerized tool for coordinating the reporting, checking, 
fixing, and testing of software problems has been developed and put 
into use: it is called MONSTR — a MONitor for Software Trouble 
Reporting. It is driven by tabled protocols defining the desired 
interactions between all the organizations listed above, and handles 
the passage of messages through the appropriate channels between them. 
MONSTR's current status is described in Chapter 10. 
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CHAPTER 3: OVERVIEW OF CURRENT STATUS, RECENT WORK 


3.1 The Present System 

The NSW system currently available to users is NSW 5.0, released 
in August 1980. It offers the following general features: 

o Twenty interactive TOPS20 tools, running under a new Foreman 
with extended workspace-handling features. 

(The last TENEX system used by NSW was converted to 
a TOPS20 during the present contract period.) 

o Ten interactive MULTICS tools, running with extensively 
rewritten and much improved Tool-Bearing Host components. 

o Two interactive IBM 360 tools, and eight IBM 360 batch tools. 
(During the contract period, the IBM 360/91 was removed from 
the system, for replacement by an IBM 3033; see section 6.6 
for current status.) 

o Core components (Works Manager and Works Manager Operator) 
and a TOPS20 Front End, interpreting and implementing a basic 
set of system commands. 

0 Better-organized user documentation, and better-coordinated 
user support, as a result of using the MONSTR coordination 
tool (see Chapter 10). 

0 Rudimentary management (node manipulation) tools, the rights 
to use which can now be assigned and removed with the 
standard tool-rights mechanism. 

0 The normal configuration of NSW 5.0 includes the followinf 
hosts: 

ISIE (T0PS20 — Works Manager, Tools) 

ISIC (T0PS20 — Tool-Bearing Host) 

RADC-TOPS20 (Tool-Bearing Host) 

CCN-360/91 (Batch and Interactive tools) 

RADC-MULTICS (Tool-Bearing Host) 

o During the period of the present contract, significant 
operational improvements have been made, particularly: 
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The release procedure has been significantly formalized, 
partially automated, and brought more under control: 

. A source code repository is maintained for the life 
of a release. 

. A semi-automatic configuration control facility has 
been implemented, to handle site-specific parameters. 

. A release-specific document is produced for each new 
release, detailing the configuration and installation 
procedures, operational procedures, and changes from 
the previous release. 

The MONSTR tool for cataloguing and tracking Software 
Trouble reports, and their associated fixes, has been put 
into use. 

A new central component, the Fault Logger, has been 
added, and the Operator Utility component has been 
modified to provide access to the Fault Logs. 

A UNIX Front End has been implemented and used 
successfully with the current system, though it is not 
officially a part of Release 5.0. 

Functionally, the current NSW system is minimally adequate. It 
has a reasonable collection of tools, but many of these tools have not 
been adequately tested. The minimal set of user commands is available 
and tested, but many needed user features are lacking — e.g. command 
macros, in file commands, I/O devices, Arpanet mail, etc. 

Performance has been improved significantly. The documentation of 
system components has been improved, but much needs to be done. 

TOPS20 is available as Works Manager or Tool-Bearing Host 
according to specification, and TOPS20 tool encapsulation has been 
extended to include the ability to REBEGIN a suspended tool, and to 
keep the user better informed about files in the tool's workspace. 
Additional encapsulated tools can be installed at will to increase NSW 
capacity. 

Eight batch tools were available on the CCN IBM 360/91, and will 
again be available on the 3033 when the NSW components have been 
adapted to run with the new operating system; more can be installed as 
needed. A major overhaul of the entire batch system has made it more 
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consistent with the rest of NSW, more flexible, powerful, operable and 
resilient. The IBM 360 interactive Foreman handled only two 
interactive tools at the time of the switchover, and its development 
will continue when the new machine is operable within NSW. 

The MULTICS implementation of all NSW Tool-Bearing Host components 
has been greatly improved during this contract period, and further 
progress is expected. 

The current status of the individual component implementations is 
presented in the Chapters through 8, by host system for the 
Tool-Bearing Host components, and by functional class for the Core 
system components and the Front Ends. 


3.2 The Redesign Effort 

During the present contract period, a group of senior NSW 
personnel, under the chairmanship of Dr. Robert Thomas of Bolt Beranek 
and Newman, was formed to reconsider the entire NSW design, and to 
draft a re-design of the entire system. This group was named the "NSW 
Analysis Group", and its charter was to rethink the organization and 
functional distribution of the NSW -- not to throw away all the 
previous design and plan an entirely new Network Operating System, but 
to reconsider all the design decisions which had been made since 197^, 
in the light of experience and the "changed directions" concept of the 
potential uses of NSW. 

The group met frequently during 1980, and exchanged working 
papers. The final report of this effort is entitled "NSW Functional 
Specification", Revised Draft September 1980. The conclusions in this 
document have largely determined the direction of planned changes in 
NSW. 


Following the lead ot this effort, a task-list was formulated for 
the changes and improvements to be made to NSW for the next two 
releases, choosing from the features of the "Functional Specification" 
those which could be applied to the present Release 5.0, and those 
which would be of greatest value for the ongoing Air Force Technology 
Demonstration. Estimates of the cost and difficulty of the items on 
this task-list have been made, and some of the new features are already 
past the preliminary design stage. This task-list, with 
amplifications, constituted the statement of work for Mass. Computer 
Associates proposal •‘or continuing effort on NSW. The task-list 
appears as an Appendix to this report. 
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CHAPTER U: CORE SYSTEM COMPONENTS 

Tasks relating to the Core System during this contract 
period naturally divide into two separate activities: 

0 baselining existing software and placing it under configuration 
management 

0 analyzing the original concepts and producing a design for a 
radically improved system. 

In this section, we discuss the first of these; the second activity 
comes under the Redesign Activity mentioned in the previous chapter. 
The subsections of this chapter give additional details on the present 
status of individual core components and list the planned extensions 
and improvements. 

The basis for configuration management of the Core System 
components is a set of TOPS-20 command procedure files which are 
used to produce executable files ('.EXE) representing a numbered 
generation of code. In addition, these procedure files automatically 
generate *.SET files which serve as a configuration index for the 
•.EXE file. The Works Manager, for example, is composed of 
approximately twenty BCPL source files. An example is shown below. 


PS:<WMSRC> 

WM.EXE.295 120320(36) 11-Mar-80 05:50sl6 

includes rel files derived from 


PS:<WMSRC> 

WMDRC.BCP.6 14904(7) 
WMFCAT.BCP.36 31664(7) 

WMIBS.BCP.122 15298(7) 

WMIETT.BCP.6 14891(7) 
WMINTJ.BCP.3 3814(7) 
WMISEM.BCP.14 20095(7) 

WMJSHO.BCP.41 2007(7) 

WMLNDS.BCP.25 15679(7) 
WMLOGS.BCP.155 24973(7) 
WMMAIN.BCP.108 14091(7) 
WMNODE.BCP.243 31813(7) 
WMOD.BCP.8 15614(7) 
WMRGHT.BCP.220 34772(7) 


7-Jan-80 10:33:47 
7-Jan-80 10:38:12 
7-Jan-80 10:46:42 
7-Jan-80 10:51:26 
7-Jan-80 10:55:30 
7-Jan-80 10:59:03 
7-j3n-80 11:07:24 
7-Mar-80 11:18:54 
7-Jan-80 10:10:28 
l4-Jan-80 11:42:33 
7-Jan-80 11:15:57 
7-Jan-80 11:31:28 
7-Jan-80 11:24:25 
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WMRUEN.BCP .322 22418(7) 
WMSCOP.BCP.77 19857(7) 
WMSEMU.BCP.85 11009(7) 
WMSKUT.BCP.18 12750(7) 

WMUTIL.&CP.211 16643(7) 
WMWMO.BCP.138 9551(7) 

WMXUTS.BCP .68 10228(7) 


25-Feb-80 15:2C:32 
7-Jan-80 11:39:53 
7-Jan-80 11:4t:20 
11-0ct-79 11:3'':30 
7-Jan-80 1 1: 4-/ : 49 
7-Jan-80 11:51:37 
11_Apr-79 11:25:31 


Total of 20 files 

Associated header/call files are 


PS:<WMSRC> 

WMRHDR.BCP .23 1257(7) 
WMRHDR.HDR.211 24576(36) 
WMRCALL.BCP .94 9080(7) 


13- Mar-79 10:55;: 17 

14- Jan-80 11:3).23 
7-Jan-80 10:17:09 


Total of 3 files 


This Tile Is named WM.SET.295 and was produced by the TCPS-20 
Directory command. The lines of text in the file identify the 
specific BCPL files including revision number and dace modified. 

A typical update scenario for the Woi'ks Manager might be the 
following: 

1. ACC notifies DMC-COMPASS that Software Trouble Report (STR) 497 
should be investigated and repairea as appropriate. 

2. DMC-COMPASS reads the description of the problem and determines 
that module WMRUEN should be corrected. 

3 . WMRUEN.BCP .322 is edited to produce WMRUEN.BCP.323 and 
re-compiled. 

4. The command procedure file MAKE-WM.DO is executed to proouct 
WM.EXE .296 and WM.SET.296 which shows that WM.EXE.29o inc.ivc.td 
the compilation of WMRUEN.BCP.323. 

5. Upon successful testing, ACC is irlormea that WM.EXE..2b7 fi^-i 

STR- 497 . 

The optimization and coordination of thi.s class of activity is a iiicjcr 
result of this contract period. 
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Operational support tools are enhanced, as well. A significant 
feature is the introduction of a system-wide parameter file named 
CONFIG.BAS. The contents of this file are lines of text; identical 
copies are placed in all component-execution directories in an NSW 
configuration. NSW components read operational parameter values from 
this file on initialization. These include directory names, time-outs, 
event logging specifiers, etc. This file contains all operational data 
which operations personnel may wish to control. Currently, all TOPS-20 
sites consult this file; work is underway at other sites to support 
this feature. 

Another support tool which is now improved is SIMWMT, a utility for 
manipulating sets of items in the Works Manager data base. A 
comprehensive manual defines and illustrates each of the 15 commands. 

Some functionality improvements are included, but of modest 
scope. Tools can now be rerun in a saved workspace; previously, the 
only option available after an aborted tool session was selective 
saving and deleting of workspace files. 

The NSW file system design includes tool specification of file 
attributes when getting and delivering NSW files. This processing has 
been added to WM-GET and WM-DELIVER. Further work is required in this 
area to remove an allowed default of TXT. The final design mandates 
that each NSW file have an operating-system dependent attribute of the 
form <0/5>-<type>; e.g., 360-PLI. 

A significant optimization has been incorporated into the Works 
Manager's database management system. The keyword components of an NSW 
file name (such as COMPASS.SATTLEY.FOXIN.MAC) are now searched in an 
intelligent order (F0XIN/SATTLEY/MAC/C0MPAS3 rather than 
COMPASS/SATTLEY/FOXIN/MAC). Clearly, lefthond keywords will appear 
often because of the hierarchical nature of the name space, and 
existing operating systems encourage or demand attributive (and 
therefore widespread) names as trailing keywords. To speed up the 
disambiguation process, then, keywords in the middle of file names are 
consulted first. Performance testing of this strategy shows that only 
1/3 as many disk accesses are required to lookup a file name. 

Finally, quite a number of minor problems have been identified 
during the baselining activity and fixed in the process of releasing 
system versions A.1 and 5.0. 
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4.1 Works Manager 

At present, the Works Manager consists of a number of identical 
concurrent instances of the same program, each one working on a single 
request at a time. Ail such processes share two common data b.ases, the 
Works Manager Table data base and the NSW File Catalogue. In addition 
to these processes there is a separate process, the Checkpointer, which 
makes periodic backup copies of the data bases. 

The Works Manager supports 31 different Works Manager procedure 
calls, which are available to other NSW processes. These procedures 
are described in the Works Manager System/Subsystem Specification and 
the Works Manager Program Maintenance Manual. 

The management/node manipulation tools are implemented entirely 
within the Works Manager. These are now invoked under the tool rights 
mechanism using the same interactive/HELP technique as batch tools. 

This has allowed removal of the specialized Front End/Works Manager 
interface formerly used, eliminating five special Works Manager 
procedure calls, and eliminating all knowledge of these tools from the 
Front End. Thus the UNIX Front End development is also freed of this 
knc wiedre. 

The file attribute mechanism was also implemented, allowing 
Foreman calls to the Works Manager for getting and delivering user 
files tc specify the file type. This feature was required to support 
future 360/91 interactive tool installation. 

The Works Manager also uses the Global Configuration File {see 
U.6), which has given it more operational flexibility. In 
particular, its timeouts on calM to remote procedures can be tuned 
without affecting other components. Also, event logging can be more 
flexibly specified, and better accommodates the divergent needs of the 
developers and operators. 

The Works Manager, which consists of approximately 25.7K lines of 
BCPL. code, is structured into a number of layers. At the top level, 
WMMAIN waits for a procedure call message from another NSW process, 
does initial decoding and validity checking of any such message, then 
dispatches the message tc the proper routine. The Works Manager 
Routines, WMRTNS, implement the 31 Works Manager Procedures. At their 
di.'jpuSc'l are a iiumbe'' of 1 o’/er-level utility packages and subsystems. 
Tnt Works Manager Table Package. WMTPKG, handles all interactions with 
Works Manager tables. It serves as an interface to the Information 
Retrieval System, INFRTV, which manages the NSW File Catalogue and the 
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Works Manager Tables. All NSW processes written in BCPL have available 
NSUPKG and BCPPKG. NSUPKG contains a number of facilities to handle 
MSG messages, create and record NSW fault descriptions, etc. BCPPKG 
provides basic utilities to handle character strings, do searching and 
sorting, and so forth. 

^.1.1 Works Manager — Future Directions 

The following list of features covers most of the major changes 
anticipated for the next two releases of NSW. 

0 Modification of the LOGIN scenario to allow the user to terminate 
a previously crashed tool-session, if he finds his node "busy" 
when he attempts to log in. 

o Modifications of the scoping and access-checking rules, according 
to the conclusions of the Redesign Effort (see Chapter 3, and 
Appendix) . 

0 Direct file access - Use access and read access: Add two new 
kinds of NSW file access. Use access means that a user has 
undisputed rights to an NSW file. When he references the file he 
is given the NSW file copy - not a private copy. Any alterations 
he makes are immediately reflected in the file. Read access 
allows a user to read the actual NSW file copy - not a private 
copy. Thus it is suitable for data base files. 

0 Tool kits - When a user runs a kit of several tools on one host, 
the workspace should be left unchanged between tools. Thus, 
intermediate files can be passed from tool to tool without 
delivery to NSW file space. Both of these features would greatly 
enhance and optimize the use of local tools. 

0 Revision numbers - Design and implement a file revision numbering 
facility. This facility must be rich enough to support 
configuration management within NSW. 

0 History file - Implement the Works Manager routines to record 
information on the History File. Design and implement at least 
some interesting management/accounting routines which acces.s this 
file. 

0 File groups - Extend the Works Manager command language so that 
whole groups of files can be copied, renamed, deleted, etc. 
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0 Full file attributes - At present only the filename portion of 
the complete NSW filename can be used for retrieval. Also, the 
use of file attributes by tools is only permitted for the Global 
File Descriptor. The implementation of file attributes should be 
completed. 

o Tool name extensions - The original concept of complete tool host 
transparency has proven unworkable. Thus, the notion of tool 
name should be extended to allow (explicit or implicit) host 
selection. By using the same mechanism as is used for files, the 
entire file lock system can also be used for tools. 

o System status commands - The NSW user needs commands to 

interrogate system status and configuration: What tools are 
available? Which resources are up? What is the system load? 

o File space maintenance and management - Operations aids to file 
space maintenance (e.g., reconciliation of the Works Manager's 
File Catalog with directories distributed at TBHs) aod management 
(e.g., relocation of seldom used physical copies from hosts which 
are short of file space to those with surplus room) need to be 
implemented. 


4.2 Checkpointef 

The Checkpointer s.atus mimics that of the Works Manager, since 
it consists largely of the entire Works Manager utility package, with a 
’"elatively small upper layer of code to implement the specific 
Checkpointer procedures. The performance improvements realized by the 
Works Manager Table Facility also apply to some Checkpointer 
procedures. 

The Checkpointer has the following characteristics: 

o Implements the FM-GUARANTEE call on the Foreman required ny cr.e 
Interim Reliability Scenarios. 

0 Mariages NSW file deletion. Files deleted by the user are 

actually deleted by the Checkpointer after a time interval, i.s 
required by the Interim Reliability flan. 

o Makes Checkpoint files of all Works Manager database files at 
configuration controlled intervals. 
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o Is robust and flexible to about the same level as the Works 

Manager itself. 

The Checkpointer received a major re-write for NSW 4.0, and except 
for one small bug-fix has remained unchanged since then. A completely 
new asynchronous remote procedure call handler was written. This 
allows the Checkpointer to make multiple simultaneous remote procedure 
calls, usually to delete files without interfering with tie timing of 
database checkpoints. 

The Checkpointer also uses the Global Configuration Database 
file, and has gained significant flexibility as a result. The external 
procedure call timeout, checkpoint interval, and waiting period before 
file deletion occurs are all under operator control. 

The Checkpointer is halted by an interrupt from the operator 
utility OPRUTL (4.4). 


4.3 Works Manager Operator 

The Works Manager Operator has been extensively used with the 
360/91 Batch Job Package since November 1978. Detail improvements have 
been made to improve reliability and job status reporting. 

WMO shares a data base (the Job Queue File) with the Interacive 
Batch Specifier (IBS) module in the Works Manager. We intend to remove 
this shared access by making all access to this data base be via 
procedure calls on WMO, which will have sole access. To this end, 
direct access to the data base by the WM to get a batch job status 
(NSW: JOB) has been replaced by a call on WMO by WM on the (new) 
WMO-SHOWJOB procedure. Direct access to the data base by IBS will be 
replaced by use of a WMO procedure, WMO-ENTERJOB, to be specified and 
implemented in the future. 

WMO also uses the configuration database file. 

Some notable characteristics of the current WMO are as follows: 

o WMO is responsible for both processing the Job Queue File and 

handling WMO procedure calls. These two tasks are handled by 

distinct instances of WMO in any given NSW system. 

(1) There is exactly one instance of WMO processing the job 
queues. A standard locking discipline guarantees that 
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precisely one such instance exists. This instance 
executes the job steps necessary to process a batch job, 
and initiates all procedure calls to external processes 
(V/M, BJP, FP). It never receives generically addressed 
MSG messages. 

(2) There are zero or more instances of WMO which receive 
generically addressed MSG messages, and handle all 
currently defined WMO procedures. These instances never 
execute job steps or initiate external procedure calls. 

Thus, these instance(s) provide external access to the 
data base. 

0 A primitive retry mechanism exists. WMO will retry an external 
procedure call indefinitely when it fails due to network or 
remote host crash. It will retry a failed external procedure 
call a maximum of three times if the failure is due to resource 
problems, e.g. no disk space. 

0 Status reports generated by WMO for display by WM (NSW: JOB) 
have been made more informative; all information supplied by BJP 
is reported. 

o The maximum number of jobs in the job queue lile is currently 6^. 
This may be increased when needed, but requires re-compilation 
and reloading of WMO. 

0 The WMO cycle number may be set manually by the WMO utility 
(WMOUTL), but does not automatically increment with each cold 
start. "Cold Start" in this version occurs only when a new 
job queue file is created. 

4.^,2 'Works Manager Operator -- Future Directions 

The Works Manager Operator program has proven to be quite reliable 
in the face of Works Manager, network, and batch-host failure; no 
significant changes have had to be made for some tine. The following 
items are features which would enhance batch operation within NSW in 
general, and they will be considered for inclusion as more, and 
different, batch hosts are added to the NSW system. 

u Background file motion - The delays perceived by the user when 
files must be transferrea or reformatted can be significantly 
reduced by pe-forming such actions in background mode. 
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o Job chaining - A desirable extension is to allow multiple batch 
tools to be run in sequence. Such a sequence should not be 
limited to just one batch host. 

0 Device I/O - A variant of background file motion is to have WMO 
control input and output from devices local to a user. 

o Support of small (or non-NSW) batch hosts - Some hosts may be too 
small to support a Batch Job Package. Also, some hosts may be 
desirable as batch hosts but may not have the required NSW 
components (MSG, File Package). The Works Manager Operator 
should be extended to use existing Arpanet protocols (FTP, RJE) 
to submit batch jobs to such hosts. 

o File groups - Extend batch tool specification facilities so that 
groups of related files can be supplied to batch tools. 


Operator Utility - OPRUTL 

The operator utility program, OPRUTL, has become sophisticated 
enough to be mentioned as a core system component in its own right. It 
can operate either stand-alone or as an actual NSW component under MSG. 
It allows the NSW to perform some maintenance functions which are 
tedious with more primitive developer-oriented utilities. Its 
capabilities are: 

0 To clean all or specified LOGIN entries out of the Works Manager 
database, e.g., to recover from a core system host crash. 

o To enter new tool descriptors into the Works Manager database. 

This is the only practical means of entering batch tools, which 
must be parsed and error-checked on entry. 

o To stop the Checkpointer via an MSG alarm. 

o To report on current NSW usage, i.e., who is logged in. 

o To reset all internal database locks (as a cleanup operations). 

o To operate the Fault Logger, displaying selected portions of the 
logs on file. 
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4.5 Central Fault Logger (FL) 

NSW 4,0 contained a prototype implementation of a centralized 
fault logging component, which has been upgraded in NSW 5.0. This 
component is intended largely to be ';n operational aid, by providing a 
single component through which the operator can receive fault messages 
from any component in the system - remote or local. 

The Fault Logger design provides foi soplii sticateci facilities ’.o 
filter incoming messages and route them to several alternative or 
multiple destinations - devices, terminals, or files. The proto .vpe FL 
simply maintains a fault message database in Arpa.net mail I'ile forraj- 
allowing mail handling tools such as HERMES to be used for inforraiicr 
retrieval. The Fault-Logger Operator commands can be accessec on-line 
through the Operater Utility (OPRUTL). 

The only component which currently logs faults to the FL is the 
TOPS20 Foreman. The next NSW release will see expanded use of a nore 
sophisticated FL. 


4.b Global Configuration Database 

NSW 4.0 included initial use of a prototype configuration 
database which supports specification and control of site dependent 
configuration data; no further development of this usage has proved 
necessary since that time, although some design work has been done on a 
generalization of the idea. It consists of a specially formatted text 
iile containitig parameters which apply both to a whole NSW 
configuration - hosts used, MSG generic classes defined, etc - and to a 
specific host in the configuration - directories used, timeout values, 
logging parameters, etc. The database is designed to be maim 
a central site and then be broadcast to all nosts in a given 
configuration, giving NSW operations a centralized means of centre'1'. 
an entire NSW configuration. 

The current database is a prototype used by most of the core 
system components and the TENEX/TOPS20 File Fdokcjge, Othe-" cenpm .t,. 
ere expected to implement use of this database in future releases 
Configuration data now used include: 

0 WM - system herald, remote call tincout, event logging. 

o CHKPTR - remote call timeout, deleted file wait interval, 
checkpoint interval, event logging. 


I 
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o WHO - remote call timeout, event logging. 

o FLPKG - remote call timeout, event logging, filespace directory 
name. 
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CHAFl'ER 5: TOPSPO ISH COMPONENTS 

The TL'NEX/T0PS20 TEH is the most advanced of the three TBHs. All 
components (MSG, Foreman, and File Package) are substantially complete 
and tested; however, major enhancements are planned for the Foreman as 
part of the Redesign Effort and the NSW 6.0 task-list (see Appendix). 
All components are transportable between TENEX and T0PS20. Since all 
the TENEX systems which take part in NSW have been converted to TOPS20 
systems, we refer in this report simply to "T0PS20" TBH components. 


5.1 MSG 

The MSG specification was producec in January 1976. It was 
revised in Decerr.ber 1976 - primarily to resolve ambiguities in tlie 
earlier document. It was extended in April 1978 to allow for support 
of multiple, concurrent NSW systems. The TOPS20 MSG component 
implements the revised and extended specification with only two 
exceptions (which are noted below). 

The T0PS20 implementation of MSG is a single executable module 
wnich will run under (TENEX, T0PS20 Version 101B, and) T0PS20 Releases 
3A arc 9. In addition to the communication functions supported for 
processes (and defined by the MSG-process interface specification) the 
TCFS20 implementation includes a powerful process monitoring and 
debugging facility, and comprehensive performance monitoring software. 

The TOPS20 implementation does not perform MSG-MSG authentication. 
Message sequencing and stream marking are not implemented (however the 
uriderlying software structure exists to support both). 

A recent modification to MSG supports rapid timeout of attempts to 
contact remote hosts which are down or where no central MSG is running; 
this markedly reduces the wait time imposed on a user who has attempted 
to use an unavailable resource. 

The implementation has also been modified to enhance its 
performance, based on extensive performance measurements completed this 
year. Changes include elimination of network connections for local 
message traffic, data re-structuring, reduction of calls on expensive 
JSYSes, and improved strategies for memory allocation. 

5.1.1 MSG — Future Directions 
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Very little additional effort is required for TOPS20 MSG. 

There are still some outstanding (but not pressing) MSG design issues: 

o Details of MSG-MSG authentication - The general mechanism is as 
specified in the MSG design document of December 1976. However, 
the details of the ARPANET protocol exchanges are being 
re-examined. 

o Maximum message size - The maximum message size is specified to 
be 65536 bytes (2**16). No implementation will accept messages 
that large. At present there is informal agreement to limit 
message size to at most 2048 bytes. 

o Process creation - This issue was skirted in the original 

specification. However, a satisfactory solution must be found 
which balances the dynamic cost of process initialization and the 
static cost of maintaining unused ready-to-run processes. 

o Optimization techniques - Compound operations like "send then 
receive" should be added, and some MSG code could be included 
inside those processes run under MSG to reduce context switching. 

o Reliability techniques - Allow for multiple hosts, process 

classes, or process instances to be considered as recipients of 
generically addressed messages (broadcasting), so that the system 
can function better in the presence of "downed" hosts. The NSW 
Fault Logger is an example of a process which could make good use 
of such a feature. 


5.2 Foreman 

The current TOPS20 Foreman (Version 1615) implements all scenario 
functions defined by the Interim NSW Reliability Plan in its most 
recent revision (1 March 1977). The Foreman only supports tools which 
run in encapsulated mode. It does not yet support the direct use of 
NSW functions by any class of tools. It currently supports 
approximately twenty T0PS20 tools in this encapsulated mode. Some of 
these tools have been extensively tested and used within NSW; others 
have merely been superficially exercised. 

The current Foreman implementation handles the "saving" of tool 
sessions (the "LNDSave" mechanism) when it loses contact with the Fn^nt 
End, or when the Front End asks that the session be saved (because the 
Front End has lost contact with its user), by copying the files in the 
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Local Name Directory into an archive directory; this frees up Ll->e 
workspace (directory) which had been in use. When the user later 
RESUMES the saved tool session, if he requests REBEGIN -- which tne 
Foreman now supports, incidentally — or TERMINATE (with delivery of 
changed workspace files), the Foreman restores the files from its 
archive directory and delivers them to NSW Filespace. If the user 
requests ABORT, the Foreman deletes the archived files. 

The TOPS20 Foreman has been extensively modified as a result of 
the extensive performance measurements made in early 1976 ana reported 
in BBN report No. 3847, "A Performance Investigation of the National 
Software Works System". Performance enhancement has been currently 
limited to reducing resource consumption by the Foreman, e.g. by 
minimizing use of expensive JSYSes, pre-allocating workspace 
directories, etc. Future work will address alternative system support 
configurations, and altered patterns of NSW communications. 

Since NSW 4.0, the Foreman has incorporated improved reporting of 
user file delivery from the tool. The Foreman also reports la^Itu to 
the iault Logger. 

5.2.1 Foreman -- Future dii'ections 

Although the T0PS20 Foreman substantially implements the present 
specification, the enhancements planned in the Redesign Effort anu 
task-list (see Appendix) have perhaps a greater impact on the T0PS2G 
Foreman than any other component, perhaps excepting the Works Manager 
itself. The following list contains the most important of these, plus 
some incidental improvements which have long been in the minds of the 
designers: 

0 Permanent integration of the TOPS20 mountable structureo 
interface 

0 Coordinated Works Manager/Foreman protocol design .ind 

implementation to have common data base items reflect local 
resource management decisions 

o Implementation of tool-specific encapsula1 eU tod intcrfa.-c.. 
handle tool peculiarities and improve performance 

0 Direct tool interface to NSW function* - i.e., non-encapsul ti*. •='d 
tool in*’«rface 
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o Design and implementation of a Foreman modified for on-line tool 
debugging 

0 Design and implementation of Foreman extensions for tool kits. 

0 Incorporation of some of the File Package’s functionality in 
order to optimize file fetching and delivery operations. 

5.3 File Package 

The TOPS20 File Package is now functionally complete. The 
task of writing Intermediate Language encode/decode for non-TENEX 
binary format files is now complete, and has been tested with the 
CCN/360 File Package for several representative binary file types. The 
current File Package version has the following characteristics. 

o All specified File Package procedures are implemented and tested 
for local, family, and non-family network transfers. Unspecified 
procedures to support the obsolete IP mechanisms in WMO have been 
expunged. 

o The Intermediate Language (ID encode/decode package has been 
re-structured for greater efficiency and maintainability. 
Encode/decode has been partitioned into three classes - text 
files, sequenced text files, and binary files; there is an encode 
and a decode module for each class, totalling six. Code size has 
increased, but both efficiency and code comprehensibility have 
been greatly enhanced. The interface between the (BCPL) calling 
routines and the (MACR010/20) service routines has been 
simplified. Implementation of binary file encode/decode is 
complete, and has been extensively tested both against itself 
(i.e. against a remote T0PS20 simulating a non-T0PS20 host), and 
against the CCN/360 File Package. We have confirmed correct 
transmission of CMS2M object files from CCN/350 to T0PS20. 

o Performance enhancements have been implemented based on the 
results of BBN's performance investigation as reported in BBN 
report No. 3847, ”A Performance Investigation of the National 
Software Works System”, Draft,Version, July 1978 by Richard E. 
Schantz. We have minimized the use of expensive JSYSes, notably 
the CNDIR (connect to directory) JSYS (average cost 220 ms per 
call). We have done so by specifying that the File Package must 
be able to create/read/delete files in its own filespace and 
Foreman workspaces without connecting to them, and letting it 


i 


-33- 





NSW Final Report for the Period Ending December 1980 


stay connected to its LOGIN directory. This has had no practical 
effect on the operation of NSW, beyond requiring that these 
directories be accessible from the system LOGIN directory. These 
enhancements have resulted in a CPU usage reduction of up to 60? 
for delivery of a file from the Foreman workspace. 

o The logging of messages sent/received via MSG is under control of 
a spec in the Configuration Database (as in WM, WMO and CHKPTR). 
When logging is disabled, CPU usage for typical FP calls is 
reduced 25? - *10?. For comparison, the FP retrieval calls 
analyzed in BBN report No. 3847, "A Performance Investigation of 
the National Software Works System", Draft Version, July 1978, by 
Richard E. Schantz, which averaged about 2,9 seconds, can be 
reduced to as low as 0.7 seconds with logging disabled. 

The File Package is written primarily in BCPL (approximately 6.9K 
statements including utilities.) The IL encode/decode package is 
written in Macro-10 and consists of approximately 1.7K instructions. 

h ^,1 hilc Package -- Future Directions 

In future releases, the capability which should be added is direct 
output of files to the user terminal. Currently, an editing or display 
tool must be run; a Works Manager command like "TYPE <file-group>" 
should be added to allow transmission directly from File Package to 
Front End. Another task which should be pursued is optimization of 
cross-net file transfers. The baud rate of such transfers should be 
Ir.cccvea and automatic restart and backup procedures in case of file 
transmission errors should be designed and implemented. 
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CHAPTER 6: UCLA IBM TBH COMPONENTS AND TOOLS 

This section summarizes the status of the UCLA IBM NSW system by 
component package as of the end of this contract period. It 
corresponds to NSW Release 5.0, which will be the last release to 
support the IBM MVT Operating System. The tools available on the 
system are also listed and discussed. 

Documentation covering the components of the UCLA IBM NSW system, 
and ti'e tools availble to NSW users through the system, is of two 
types: UCLA technical reports and UCLA NSW documents. UCLA Technical 

reports are the direct reports to DARPA from contract personnel. UCLA 
NSW documents are produced for the NSW development or user community. 
They are delivered to the NSW Operations Contractor, in 
machine-readable form, for distribution upon request. The reader is 
referrea to UCLA Technical Report TR-27, the Final Report for their NSW 
contract, for a complete set of references to these documents. 
(Citations in [square brackets] in this chapter refer to references in 
that re ort.) 


6.1 MSG Central 

MSG central [TR-12] is a set of routines that execute as a part of 
the UCLA ARPANET Network Control Program (NCP). It contains all the 
machinery necessary to create and destroy jobs, to execute the 
processes that are required to service generic message requests, as 
well as that needed to switchboard messages between executing processes 
on the local and remote hosts. 

MSG central is written in Assembler language, using a set of 
subsupervisor interface macros that are specific to the UCLA NCP. It 
is not directly executable outside this context; however, the UCLA NCP 
has been successfully exported, and MSG could be exported concurrently. 

MSG communicates with actual NSW processes via the UCLA 
interprocess communication mechanism known as the Exchange [TR-5]. 
Exchange is an exportable package. The other end of this 
communications link is managed by subroutine packages, so its 
elementary characteristics are not known to the using process. 


6.2 The BJP Package 
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The BJP package consists of the modules that perform the Batch Job 
Processor function [UCNSW-207]. It allocates and frees temporary 
workspaces as batch jobs are created and finalized by the Works Manager 
Operator (WMO) core component. It submits local control-language 
data sets provided by WMO, monitors the submitted jobs, responds to 
status queries, and notifies WMO ansynchronously when a job is 
completed. 

The BJP is implemented on the UCLA system as a continuously 
available single MSG process executing as a swapped TSO job. The 
single process is initiated by MSG central whenever it is itself 
initialized. The process name "BJP” carries the UCLA local 
"queue-generic-messages" attribute, which causes a single process 
service all incoming generic requests directed to that name. 

Because the MVT operating system does not itself include 
mechanisms for submitting jobs from internal processes, the MVT 
implementation of the BJP is "ied heavily to UCLA modifications tf.- MVT. 
These modifications are complex, and are intertwined with other ICLA 
modifications to the point tliat the BJP should not be considered 
exportable in its present form. This will not be a problem in the 
future implementation for the MVS operation system. 

The BJP lacks a routine to clean up the queues, jobs, and datasets 
that may be left lying around after a change in WMO cycle number. The 
BJP does not clean up a directory at BJP-ENDJOB time. 

The routine that reads the BJP's parameterization data set does 
not function correctly. Fixing this will probably be tied to 
implementation of the NSW Uniform Operations Interface concept. 


6.3 The FOREMAN Package 

The Foreman package consists of routines thet implsmenc toe !!S’ 
Interactive Foreman function [ACC-FM]. It is executed on the UC(A 
system as a swapped TSO job, of which instances are materialized b'* MTG 
central on response to incoming generic messages. 

Basically, the Foreman implements a "begintool" transaction which 
initiates a user-requested tool session. This transaction caTies a 
"program name" which directs the Foreman to a special program stored in 
a local data base. This program is written in a locally defined 
language to be interpreted by the "Encapsulator Command Interpretor" 
(ECI) subcomponent of the Foreman [UCNSW-206]. The Foreman calis the 
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ECI to execute this program, which defines the file setup and cleanup 
and the "personality" of the tool. At indicated points in this 
execution, the ECI returns control to the Foreman to attach an 
indicated program, typically the native-mode tool program itself, as a 
concurrent process. On completion of that program, the ECI resumes 
interpretation of its program. 

The Foreman also responds to "endtool" transactions. Because the 
tool and the Foreman are concurrent processes, the Foreman remains 
receptive to such transactions from the NSW core system during tool 
execution; however, due to the blocking mechanisms of the MVT operating 
system, both the Foreman and the tool are blocked when the tool is 
waiting for keyboard input from the user. This causes operational 
problems, and makes it inadvisable to terminate a UCLA-mounted tool by 
any mechanism except the tool's own voluntary termination command. 

In the current implementation, the ECI operates as a synchronous 
subroutine of the Foreman, with the unfortunate result that the Foreman 
is not receptive to core-system requests during ECI operation. 

Due to the characteristics of the MVT supervisor, the Foreman can 
not be sufficiently isolated from the tool. The kind of tool that runs 
undebugged programs can destroy the Foreman. Because of this. Foreman 
processes are never reused. Once a Foreman instance has completed, it 
is destroyed, and any subsequent Foreman request must create a new 
instance of the executing Foreman program in order to materialize a new 
MSG process. 

Only encapsulated tools are supported, technically, and then only 
through pre- and post-processing by the ECI. The Foreman does not 
actually monitor tool execution, and no Foreman/Tool interface for 
"new" tools is presently defined. 

Due to critical main-storage constraints in MVT/TSO, the .'^oreman 
can not maintain an LND, so recovery across crashes is not supported. 

In keeping with this, the "savelnd" and "rebegintool" procedure calls 
to the Foreman are not properly supported. They are accepted, but they 
function more or less like the "endtool" and "begintool" requests. The 
more esoteric "starttool" and "stoptool" are unimplemented only due to 
lack of demand. 

The routines that read the configuration data set do not function 
correctly. Fixing this will probably be tied to implementation of the 
NSW Uniform Operations Interface conceot. 








NSW Final Report .''or the Period Ending December 1980 


6.4 The "FILE PACi''AGE" Package 

The "File Package" package consists of routines that implement the 
NSW File Package function [UCNSW-204, UCNSW-203]. It is implemented on 
the UCLA system as a swapped TSO job, of which instances are 
materialized by MSG central in response to incoming generic messages. 
Unlike Foreman processes, File Package processes are reusable. That 
is, when an instance of a File Package is complete, the same program 
instance will rematci’ialize as a new NSW process which can be used to 
satisfy another incoming generic message. 

The File Package responds to five basic procedure calls: 

1) The "import" procedure: moving or copying data into local 
NSW filespace from an external directory, another host, or 
the temporary workspace assigned to an NSW batch or 
interactive tool. 

2) The "export" procedure: copying data from local NSW 
filespace to an external directory or a tool workspace. 

31 The "send" procedure: copying data from any local data set 
to another host. 

41 The "transport" procedure: copying data from an external 
directory or another host into another local external 
directory. 

5) The "delete" procedure: deleting a file copy from any 
local filespace. 

In servicing any of these procedure calls, the File Package 
performs operations that consist of combinations of several 
almost-independent capabilities: 

a) Making equivalent copies of files. 

b) Translating files from one local representaton ("file 
type") to another. 

c) Moving file data between hosts. 

d) Encoding and decoding the standard NSW Intermediate 
Language (ID. 
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e) Deleting copies of files. 

Due to restrictions in the MVT data security system, the File 
Package (as well as any other NSW component) can only access data sets 
stored under its own charge number. Passwords cannot be used to 
override this constraint. 

ASCII-type format effectors are not supported in other than 
internal forms. The tab descriptor of the GFD is lost when the GFD is 
relayed to a foreign host in a SENDME call. 

6.5 Tools Installed 

During the course of the contract, various tool programs have been 
mounted on the UCLA NSW system. Some of these were installed under IP 
and found their way into the full NSW implementation by default. 

Others have been installed through a careful design, validation, and 
documentation procedure. All were installed prior to the availability 
of a comprehensive tool-mounting procedure from the newly-commissioned 
NSW Tool Manager Contractor. 

6.5.1 Well-Documented Tools 

These tods represent the beginnings of a comprehensive workbench 
system for program development on IBM systems under NSW. Each is 
represented by at least one user document. 

0 Editing 

The TSOEDIT tool [UCNSW-107] allows the NSW user to create and 
maintain text data files on the UCLA system interactively. 

o Browsing 

The DISPLAY tool [UCNSW-106] allows the NSW user to browse 
existing text data files interactively. It is particularly 
useful for examining the outputs of batch tools. 

o Library Maintenance 

The "Interim Library Management" (ILM) tool kit [UCNSW-101] 
allows the NSW user to create and maintain library files on the 
UCLA system. Library files are not supported by NSW explicitly, 
but are required use IBM programming systems. Therefore, we 
support them implicitly through NSW tools pending the 
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implementation of UCLA’s recommendations for direct NSW library 
support [TR-16]. There are presently ten tools in this kit. 

Some are batch, but most are interactive. There is also a 
document on installing this kit [UCNSW-212]. 

o PL/I Program Development 

The PL/I tool kit [UCNSW-103 j allows the NSW user to compile, 
link, and execute (with some restrictions) programs written in 
PL/I for the IBM Optimizing compiler [IBM-PL/I]. There are 
presently four batch tools in this kit. There is also a document 
on installing this kit [UCNSW-211]. 

6.5.2 Older Tools 

The tools that remain in the UCLA NSW system due to their 
conversion from the IP system do not have formal user documents, 
pending their re-installation using tool installation procedures to be 
specified by the NSW Tool Manager. These tools are: 

FORTRAN: compiles and executes a FORTRAN program. 

ASM80: a cross assembler for the INTEL 8080 MPU. 

PLM80: a cross compiler for the INTEL 8080 MPU. 

MACR020: a cross assembler for the AN/UYK-20 computer. 

CMS2-M: a cross compiler for the AN/UYK-20 computer. 

SPPCOBOL: a structured-programming package for COBOL. 


6.5.3 Future Tools 

The PL/I tool kit is intended to be the first of a comprehensive 
set of compatible tool kits supporting program development using the 
native languages of the IBM System/360 and 370 families [UCNSW-in2]. 
These kits will support FORTRAN, COBOL, Assembler, and any other 
languages for which there are compilers available and interest in the 
NSW user community. 


6.6 IBM 3033 MVS TBH — The Future System 
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The personnel implementing and maintaining the UCLA IBM NSW system 
happen also to be the people responsible for the basic Arpanet software 
on that system, and hence are obliged to first work to bring the new 
machine (IBM 3033) back onto the Arpanet running with the new operating 
system (MVS), before turning their attention to the NSW software. 

Thus, the future directions planned for the UCLA IBM NSW system can be 
summarized as follows: 

Restore the functionality which was present in the 360/91 MVT 
version of the NSW system, but as reprogramming is required, do 
it in conformance with the best redesign ideas which have arisen 
in the course of implementing the previous version, and in 
accordance with the extensions planned to the NSW protocols and 
Management Plan. 

For the individual.components, this amounts to: 

o The BJP must be redesigned and written from scratch. 

o The Foreman must be heavily modified to gain the capabilities 
deliberately left out of the MVT version; however, it will run 
without those capabilities with little conversion. 

0 The File Package needs little conversion; however, when the 

extended protocols for FP-WM-FM interactions are ready, they will 
have to be implemented. 

0 MSG needs conversion to use IBM virtual terminals instead of the 
UCLA-specific ones in MVT. 

o All subroutine packages need minor revisions. 

o The tools all need to be re-installed, this time using more 
proper installation procedures, in coordination with the Tool 
Manager contractor. 
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CHAPTER 7: MULTICS TBH COMPONENTS 

During the present contract period, the MULTICS NSW system has 
been materially improved, both in terms of the reliability and 
correctness of the components, and in terms of the number of tools 
available. Considered by component: 


7.1 MSG 

Previously, the Multics MSG server depended on an ad hoc, 
unsupported "Tasking Software" extension to the operating system; that 
Tasking Software is now supported by Multics TBH Support and has 
already been upgraded. 

MSG has been modified for support of extended-leader host 
addresses, as required by current Arpanet protocols. 

Many MSG bugs have been fixed (See appropiate STRs). 


7.2 Foreman 

The original version of the Multics Foreman was implemented to 
support tools which were written (or rewritten) specifically for use 
within NSW; the QEDX-RM tool, for instance, is a specially tailored 
version of a standard Multics editor containing explicit calls on 
Foreman functions where needed. As the emphasis in NSW has shifted 
more in the direction of packaging existing tools for easy cross-net 
access through NSW, an encapsulation technique has been developed and 
implemented for the Multics Foreman, permitting a larger number of 
tools to be made rapidly available (10, at present). Effort during the 
present contract period has been in two directions: improving the 
Foreman program to correctly execute all the relevant scenarios and 
connection protocols; and improving the encapsulation of individual 
tools. 

The robustness of the Foreman has been increased, especially in 
the areas of detecting and reestablishing broken direct connections to 
the Front End. 

Previously, the only safe non-ABORT method of terminating a tool 
session was to use the tool’s own internal termination command; but 
now, the Foreman is able to respond to unexpected specific messages, 
allowing the QUIT TERMINATE and FM-LND--SAVE scenarios to work properly. 
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New tools have been added since the last interim report: 

ada, ada-lstat, run-ada 

— Ada T & E Test Translator 

smite 

run (version 35.2) . 

Version numbers now work correctly, but the user interface with 
tools cannot yet make a direct reference to a file with the version 
number in that reference. Version numbers are there for status 
information only. 

Multics tools follow an approach to the file system which differs 
from that of its TOPS-20 counterpart in that a file write operation is 
considered to be a global one, not just to a local workspace copy. 

Therefore, in the' event of a crash, the highest version local copy will 
be equivalent to the global copy. This accomplishes two things: 

a. Read and write operations appear to the user to be NSW 

global operations with the workspace copy as transparent as 
possible. 

t. LND-Saving is not necessary since file delivery is done as 
needed, not at the end of a tool session. 

Many FOREMAN bugs were fixed (See appropiate STRs). 


7.3 File Package 

The Multics File Package is a fairly reliable component. It 
conforms closely to the specification, and supports file encodement 
into Intermediate Language about as well as do the other TBH File 
Packages. Binary file transfer to non-Multics hosts is not supported, 
but is not required by any currently installed tools. 

Local file types supported include: 

a. MTX-TEXT which is like the default TXT file and assumes a 
stream file of ascii bytes. 

b. MTX-LIBRARY which is physically a Multics directory. This 
file type does not support transfers to other hosts, i.e., 
it is PRIVATE. 
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7.^ Multics TBH — Future Work 

0 Multics components are very close to being fully documented. 

° Lf?ia?e'^°‘' Package is scheduled to be added to the Multics TBH 
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CHAPTER 8: Front End Components 

There exist two operational Front End components for the present 
NSW System: The UNIX Front End, produced by Bolt Bcranek and Newman, 
and the T0PS20 Front End (the "COMPASS FE"), produced by Massachusetts 
Computer Associates. There has also existed the "SRI FE", Produced by 
SRI International, which is no longer maintained, although it did 
successfully work with earlier versions of the NSW. 


8.1 UNIX Front End 

This component is produced under an entirely separate contractual 
arrangement, and has not as yet been formally incorporated into the NSW 
User System; Massachusetts Computer Associates, as Architecture Control 
Contractor, has not had any official responsibility for testing or 
evaluating the program. But as a part of our ACC duties, we have 
maintained regular communication with BBN personnel working on the UNIX 
FE, and all protocol changes affecting FE operation have been 
coordinated with their effort. Informally, we have operated the UNIX 
FE in the Development System (a test NSW system separate from the User 
System), and find it very sturdy and pleasant to use. 


8.2 T0PS20 Front End 

A user of the NSW User System (which is normally accessible only 
through the T0PS20 FE) will note some differences in what he sees on 
his terminal, compared to the system as it was at the beginning of this 
contract period: 

o The Front End has an "Are You There" response, elicited by typing 
Control-T, which assures the user that the FE program is running, 
gives the date and time, and lists the connection state of ea''.;i 
of the tools which are available for RESUMEing. 

o All changes in the state of the connection to a tool are reported 
to the user as they happen: 

"Awaiting connection" is typed every five seconds if the tool 
connection is not yet open when the Works Manager's 
reply-authorization is received; 

"Connecting to <tool-instance>" is typed when the connection 
initially opens, when the user RESUMES the tool after having 
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slewed -iway, or after the reply to a Help-request message has 
been sent to the Works Manager. 

"Disconnecting f'"om <tool-instance>" is typed when the user 
slews away from the tool (with Control-N), or when a 
Help-request message arrives from the Works Manager on behalf 
of the tool. 

o The functionality of the RESUME command has been extended in the 
Foreman, Works Manager, and Front End, so that the user now has 
the option to REBEGIN a saved tool (a tool session which was 
previously interrupted by communication failure). 

o The former FASTOUT and MOVELOG operations have been subsumed as 
sub-commands to the LOGOUT command. 


The most important changes in the T0PS20 FE, though, have been 
invisible to the user, having to do with the handling of network 
connections. Numerous errors and misunderstandings have been fixed, in 
a layered fashion -- since it was only after some were fixed that 
others were able to appear. The most important of these repairs were: 

0 The FE now no longer ever waits for a Close-connection operation 
to complete before proceeding. Previously, if the Close was part 
of the cleanup when a Foreman host crashed, the FE-host MSG 
process would wait for an excessively long time for an 
acknowledging Close from the other host, and the FE process would 
appear to be hung. Secondarily, the out-of-line handling of 
Close-connection operations speeds up the LOGOUT FAST and 
Autologout procedures. (This problem became clear only when an 
earlier misdirection of the lost-connection interrupt signal was 
discovered and fixed.) 

o The Autologout scenario has long been the shakiest part of the FE 
program. Once the tool-connection handling had become reliable, 
it turned out that '-he Autologout procedure was still failing 
because of a mistaken treatment of I/O to the lost terminal. This 
has now been repaired, and lost connections to the user's host 
now reliably initiate the Autologout scenario as specified in the 
Interim Reliability Plan. 


On the whole, the shortcomings of the present version of the 
T0PS20 Front End program lie not in failures to perform adequately the 


i 
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functions it purports to perform, but rather in the absence of 
desirable functions and modes of operation which could be included. 
Most of these are in consonance with the changes called for in the 
Redesign document, and are discussed below. 

The principal weakness of the present version of the program is 
that, if the Works Manager crashes, the FE will wait indefinitely for 
reply to any message it might have sent to the Works Manager, and the 
user has no choice but to hang up his connection. To repair this 
shortcoming will take a restructuring of the message-handling 
procedures in the FE, which would be helpful in other respects as well 
allowing multiple WM commands to be in process simultaneously, for 
instance, as the UNIX FE now does. 


8.3 T0PS20 Front End -- Future Plans 

A number of the changes proposed for the next NSW System Releases 
involve changes to the Front End (see Appendix). Correspondingly, 
the principal modifications projected for the TOPS20 Front End program 
are those required for the proposed system changes; with the 
possibility of making a few desirable local improvements along the way 

These projected modifications are: 

0 A number of new commands, or additions of arguments to current 
commands, which involve no change in FE programming other than 
the recognition and translation of the commands themselves: 

Additional arguments to the USE (service) command (host, 
workspace, arguments of call to the service invocation, 
etc •) . 

System status-information commands (show descriptors, current 
users, host configuration and status, etc.). 

Any other new Works Manager commands (service registration, 
etc.) . 

0 A TYPE command for typing text files directly on the user's 

terminal, without having to start up a service (e.g., an editor 
tool) to perform the typing. 

o Provision for direct connections to registered services other 
than through a Foreman process -- the "native mode" services and 
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ICP contact-socket tools. 

0 A command for "detaching" from a Foreman session at the user's 
request, that is, voluntarily causing the "saved session" 
activity which now occurs only when the user's connection to the 
FE is lost. 

o Additional communication conventions between the FE and Foreman, 
covering user signals for talking to the Foreman rather than the 
tool, and for notifying the user that some output is waiting for 
him to see from a tool he is not actively communicating with. 

o "Local" commands (not forwarded to the WM) for allowing the uier 
to set his terminal-type and other parameters to improve FE 
handling of the user-interface communication. 

0 Complete recompilation of the FE program with the improved BCPL 
compiler; this will improve the efficiency of the running code, 
and permit a number of localized improvements to be made. It 
must be done, however, only in synchrony with the recompilation 
of the TOPS20 utility packages used in the Works Manager, File 
Package, Checkpointer, Operator Utility, etc. 
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CHAPTER 9: QUALITY ASSURANCE 

9.1 Introduction 

The objective of Quality Assurance is to provide continual, 
reliable access to a product whose limitations are both known and 
removable over time. It is the assurance that whenever a user accesses 
the service, it has at least the quality of the product previously 
accessed, and that notification of any trouble which might arise 
can be dispatched to a chain of organizations which can address 
it in a timely and effective manner. Attainment of these objectives 
rests upon Configuration Management (CM) - to ensure that the approved 
system revision is currently operational - and Software Trouble 
Reports (5TR) - to respond to and coordinate the removal of limitations. 

In this section, we discuss Quality Assurance methods for 
the NSW as a whole. Most CM is performed as a supporting service 
by Data Technicians, but response to and removal of limitations 
requires coordinated participation of many persons: users, operations, 
management, and developers. 

9.2 Configuration Management 

CM is to warrant that at all times, the service being offered 
is that approved by the Policy Group. As NSW is a distributed group 
of heterogeneous systems, an auditing style of CM is employed. 

That is, periodic inspections of the names and revision level 
of service components are compared with the system "inventory" 
as of its official release. Such auditing should ordinarily proauce 
no exceptions and is best viewed as a watchdog who seldom 
"barks". Should changes appear, management can trace them to 
reduced limitations, new features, etc. The day-to-day 
operation can be delegated to the specialist 

organization; management personnel need only perform periodic audits. 

The "inventory" in the NSW context is really the configuration 
index of a distributed, heterogeneous system. We decided 
to produce on each host a local configuration index, and then to copy 
those indices to a single host in order to construct a system 
configuration index. Each operating system has a tool suitable for 
constructing a local configuration index with some useful prooerties: 
text files, each line of which identifies a file in a given context 
(directory, ]ibrary, etc.), by name and by the time of creation 
or most recent modification. TOPS-20, TSO, and MULTICS 
offer DIRECTORY, PDS, and library-map, respectively. Procedurally. 
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the Data Technician can index an NSW system by successively logging 
into each component host, running its local index-producing 
tool, copying the result to a single site, and finally 
composing the system configuration index by concatenating the local 
indices. 

Every time an approved change is made, an index 
is prepared and retained. This approved index is used as a comparand 
in subsequent configuration audits. The periodic audits are performed 
by constructing the (current) configuration index and using TOPS-20's 
FILCOM tool for comparison. This is the motivation for single lines of 
text for each item described: if differences are found, FILCOM 
will display them in a fashion that is directly usable in pursuing 
the reason for the change. An example index and change notice are 
shown belov/: 


Configuration Index for host USC-ISIC as WMH 
Configuration files (C. Muntz) 

MSG-GENERIC-NAMES.;103 585(7) 4-Jun-80 05:19:13 

MSG-NETWORK-CONFIGURATION.;102 73(7) 6-May-80 08:14:30 

CONFIG.BAS;514 1001(7) 10-Sep-80 02:40:13 

F0RC0MFILE.BASE;3 512(0) 12-Mar-80 11:55:06 

Msg (R. Thomas) 

MSG.SAV;108161 48640(36) 10-Sep-80 02:33:46 

Front End (K. Sattley) 

FE .SAV;65201 33280(36) 8-Sep-80 05:11:33 

FETHDL.EXE;66300 36664(36) 8-Sep-80 05:23:25 

UNTLNT.EXE;3202 19*^56(36) 30-Jul-80 06:07:38 
D1snatcher (R. Schantz) 


-50- 




NSW Final Report for the Period Ending December 1980 


DSPCHR.SAV ;1310 6656(36) l7-Apr-79 13:55:22 

NSWROOT.SAV;23':0 6144(36) 17-Apr-79 19:07:55 
File Package (C. Muntz) 

FLPKG.SAV;25700 46592(36) 22-May-80 05:05:47 
LOGUTL.SAV;4000 19456(36) 11-Mar-80 07:11:11 
Foreman (S. Swernofsky) 

FOREMAN.SAV;1613 26112(36) l8-Jul-80 13:11:00 
MKCOM.SAV;1611 6144(36) l8-Jul-80 13:25:20 

LOGRED.SAV;1509 4608(36) 13-Aug-79 09:38:18 

Works Manager (C. Muntz) 

WM .SAV;29602 120832(36) 17-Aug-80 15:18:17 

CHKPTR.SAV;3401 86528(36) 20-Aug-80 14:47:07 
WM0.SAV;16900 33792(36) 11-Mar-80 06:59:01 

OPRUTL.SAV;1640 83456(36) 23-Jun-80 04:48:28 
WMOUTL.SAV ;14700 30208(36) 11-M3r-80 06:58:07 
SIMWMT.SAV;5800 85504(36) 25-Jun-80 •!0:53:27 
DMPUTL.SAV;1100 64000(36) 11-Mar-80 07:23:11 
SIMINF.SAV;7300 58368(36) 25-Jun-80 10:55:01 
DBSTAT.SAV;600 65536(36) 11-Mar-80 07:24:07 

SIMWTF.SAV;1400 64512(36) 11-Mar-80 07:19:26 
Fault Logger (F. Ulmer) 

FL .SAV;2010 36635(36) l8-Jui-80 13:09:18 






NSW Final Report for the Period Ending December 1980 

FL0PER.EXE;2010 3^304(36) 18-Jul-80 13:58:^7 
FLTEST.SAV;2000 25088(36) 20-Jun-80 10:19:18 
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... A Sample Change Notice 


;C0NFIG.INDEX;2 & CONFIG.WORK;56 9-Jun-80 0811 PAGE 2 
LINE 35, PAGE 1 

1) FLPKG.SAV;25500 46592(36) 11-Mar-80 06:56:56 
LINE 35, PAGE 1 

2) FLPKG.SAV:25700 46592(36) 22-May-80 05:05:4? 

LINE 41, PAGE 1 

1) FOREMAN.SAV;1610 26112(36) 10-Mar-80 12:20:35 
LINE 41, PAGE 1 

2 ) FOREMAN.SAV;1612 26112(36) 3-Jun-80 03:35:37 


LINE 49, PAGE 1 

1) WM.SAV;29300 120832(36) 11-Mar-80 07:12:15 
LINE 49, PAGE 1 

2) WM.SAV;29500 120832(36) 23-May-80 12:50:09 
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Our original goal was CM auditing which could be performed 
by a Data Technician, with other personnel involved only if changes 
were found. If differences like the previous example are found, they 
may be forwarded to configuration managers for disposition; if'FILCOM 
displays "NO LINES CHANGED" the CM audit has terminated with the 
watchdog silent, 

9.3 Software Trouble Reports 

If limitations are to be known and removed over time, 
each problem must be centrally reported and new ones carried in a 
journal for the life of the product. Consider the needs of different 
organizations: 

o User - Where can I report my problem? How can I work around it? 

When will it be fixed? 

o Developer - Are there any problems with my pieces? Here is 
a component which fixes problems a and b. 

o Managers - Which problems will be addressed by the next system 
release? What is the workload for each of the developers? 

Rank the outstanding problems by severity. 

As contrasted with the CM watchdog who seldom barks, 

STR processing requires direct participation by nearly every project 
person. Each STR will be in a different state according to its 
progress and the subset of project staff affected. 

Clearly, no existlnff tool rnniH mopt such needs, so MONSTP 
was specially designed and built - based largely on the Works Manager's 
database system, but operating over a computer-based problem 
journal instead of NSW's database of names, permissions, and file 
catalogue entries. This system is used by project personnel in all categories 
to report and deal with limitations. 

9 .^ Testing 

The large number of interacting components found in a network 
operating system dictates a requirement for extensive testing. Each of 
these components must be unit tested, of course, and the set of 
components on a single host can be tested by usual methods. Once 
each host can function locally, the combinatorics of integration 
testing immediately arise. For example, the combination of hosts 
involved when an interactive tool needs to get a (possibly remote) 
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NSW file is roughly cubic in the number of hosts in the network: 
FE*FM*FP, where the three variables are respectively the number 
of hosts offering Front Ends, Foreman, and File Packages. 

Our approach towards dealing with such a large number of test 
scripts is random testing by our Data Technician on a daily basis. 

Using NSW tools, we have written a program which - using a random 
number generator and tables of probabilities - chooses a different 
sequence of host locations and tool choices on each execution of the 
generator. (As the random seed is the time since midnight in hundredths 
of a second, duplicate runs are acceptably impossible.) The table 
of probabilities and two resulting test scripts are shown below. These 
scripts are then run by the Data Technician, but given availability 
of a testing tool, the script could be run automatically. 
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TEST CONFIGURATION 


IS AS FOLLOWS: 


HOST NAME AND CHOICE 

PROBABILITY 

USC-ISIC 

18 

USC-ISIE 

1 ft 

UCLA-CCN 

22 

MULTICS 

22 

RADC-20 

20 


HOST NAME OFFERING TOOL 

NAME AND PROBABILITY 

USC-ISIC 

SOS-IC 

15 

USC-ISIE 

SOS-IE 

15 

UCLA-CCN 

FTN-UC 

25 

MIIT.TTCS 

OEDXRM 

30 

RADC-20 

S0S-R2 

15 


HOST NAME OFFERING FTP 

AND AND PROBABILITY 

USC-ISIC 

FTP-IC 

30 

USC-ISIE 

FTP-IE 

30 

RADC-20 

FTP-R2 

40 


HOST NAME OFFERING FRONT END AND PROBABILITY 


USC-ISIC 

USC-ISIE 

RADC-20 


30 

35 

35 
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GENERATE TEST SCRIPT WITH 20 STEPS 

LOG INTO NSW USING FE AT RADC-20 
USE FTP-IC TO SEND FILE TO USC-ISIE 
TRANSPORT FILE FROM USC-ISIE TO UCLA-CCN 
USE FTP-R2 TO GET FILE FROM UCLA-CCN 
EXPORT FILE TO UCLA-CCN 
TRANSPORT FILE FROM UCLA-CCN TO RADC-20 
LOG OUT OF FRONT-END AT RADC-20 


LOGIN TO FRONT-END AT USC-ISIE 
IMPORT FILE AT RADC-20 
EXPORT FILE TO UCLA-CCN 
IMPORT FILE AT UCLA-CCN 
USE FTP-IC TO SEND FILE TO UCLA-CCN 
USE FTP-R2 TO GET FILE FROM UCLA-CCN 
LOG OUT OF FRONT-END AT USC-ISIE 


LOGIN TO FRONT-END AT RADC-20 
USE FTP-IE TO SEND FILE TO MULTICS 
TRANSPORT FILE FROM MULTICS TO UCLA-CCN 
LOG OUT OF FRONT-END AT RADC-20 


LOGIN TO FRONT-END AT USC-ISIE 
IMPORT FILE AT UCLA-CCN 
EXPORT FILE TO UCLA-CCN 
USE FTP-R2 TO GET FILE FROM UCLA-CCN 
USE QEDXRM TO MAKE ANOTHER NSW FILE COPY 
EXPORT FILE TO MULTICS 
LOG OUT OF FRONT-END AT USC-ISIE 


LOGIN TO FRONT-END AT RADC-20 
IMPORT FILE AT MULTICS 
LOG OUT OF FRONT-END AT RADC-20 


LOGIN TO FRONT-END AT USC-ISIE 
USE FTP-R2 TO SEND FILE TO USC-ISIC 
LOG OUT OF FRONT-END AT USC-ISIE 


LOGIN TO FRONT-END AT RADC-20 
USE FTP-IE TO GET FILE FROM USC-ISIC 


-57- 










NSW Final Report for the Period Ending December 1980 


SCRIPT IS NOW COMPLETE 
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GENERATE TEST SCRIPT WITH 20 STEPS 

LOG INTO NSW USING FE AT RADC-20 
EXPORT FILE TO MULTICS 
LOG OUT OF FRONT-END AT RADC-20 


LOGIN TO FRONT-END AT USC-ISIC 
USE FTP-IE TO GET FILE FROM MULTICS 
LOG OUT OF FRONT-END AT USC-ISIC 


LOGIN TO FRONT-END AT RADC-20 
EXPORT FILE TO UCLA-CCN 
USE FTP-IC TO GET FILE FROM UCLA-CCN 
USE FTN-UC TO MAKE ANOTHER NSW FILE COPY 
LOG OUT OF FRONT-END AT RADC-20 


LOGIN TO FRONT-END AT USC-ISIE 
USE SOS-IE TO MAKE ANOTHER NSW FILE COPY 
LOG OUT OF FRONT-END AT USC-ISIE 


LOGIN TO FRONT-END AT RADC-20 
EXPORT FILE TO USC-ISIC 
USE FTP-IE TO GET FILE FROM USC-ISIC 
EXPORT FILE TO UCLA-CCN 
LOG OUT OF FRONT-END AT RADC-20 


LOGIN TO FRONT-END AT USC-ISIC 
TRANSPORT FILE FROM UCLA-CCN TO UCLA-CCN 
USE FTP-IE TO GET FILE FROM UCLA-CCN 
LOG OUT OF FRONT-END AT USC-ISIC 


LOGIN TO FRONT-END AT USC-ISIE 
USE CEDXRM TO MAKE ANOTHER NSW FILE COPY 

USE FTN-UC TO MAKE ANOTHER NSW FILE COPY 

USE SOS-R2 TO MAKE ANOTHER NSW FILE COPY 

EXPORT FILE TO USC-ISIC 
IMPORT FILE AT USC-ISIC 
USE QEDXRM TO MAKE ANOTHER NSW FILE COPY 

USE SOS-IE TO MAKE ANOTHER NSW FILE COPY 

LOG OUT OF FRONT-END AT USC-ISIE 


LOGIN TO FRONT-END AT RADC-20 
USE QEDXRM TO MAKE ANOTHER NSW FILE COPY 
LOG OUT OF FRONT-END AT RADC-20 
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LOGIN TO FRONT-END AT USC-ISIE 
EXPORT FILE TO RADC-20 

SCRIPT IS NOW COMPLETE 
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At the current time 
run. During the following 
tests on a daily basis. 


only a few such test scripts have been 
contract periods, we intend to run such 
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CHAPTER 10: MONSTR -- A MONitor for Software Trouble Reporting 

MONSTR, the MONitor for Software Trouble Reporting, was a response 
to the chaotic situation which existed in the area of bug reporting, 
tracking, and correction within the NSW project. During this contract 
period, work on MONSTR proceeded as follows: 

o April 1979 - November 1979: Writing and critiquing the A-level 

System Specification and the User’s Reference Manual. 

o December 1979 - February 1980: Design of MONSTR as described in 

the User’s Reference Manual. 

o March 1980 - July 1980: Implementation. 

o June 1980: Release of MONSTR 1.1 to NSW project personnel. 

o October 1980: Release of MONSTR 1.2 with increased reliability. 

o January 1981: Release of MONSTR 1.3 with archival capability. 

Currently, MONSTR manages nearly ^00 accive STRs and is used daily 
to produce status reports which, prior to the existence of MONSTR, were 
virtually impossible to obtain. 

The following commands are available in MONSTR version 1.3: 

LOGIN ACCEPT ASSIGN-RESPONSIBILITY 

MOVELOG READ STATUS 

LOGOUT HISTORY SUMMARIZE 

HELP IN-BOX CLASSIFY 

CREATE OUT-BOX RETRIEVE 

DISPATCH RESPOND REPORT 

ARCHIVE 

MONSTR has most of the functionality described in the User’s 
Reference Manual. The chief deficiency is the inability to FREEZE 
transactions, MODIFY or CANCEL them, and then THAW them to continue 
their progress. 

MONSTR has exhibited some serious, unforeseen operational 
problems, due almost entirely to the fact that its database support is 
the Works Manager Table Facility and the Information Retr eval System. 
The WMTF and IRS are both well-written pieces of code, but MONSTR is 
exercising them at their design limits. At this time, the MONSTR 
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database is ten times the size of the Works Manager database (in number 
of pages), holds many more entries, and receives far greater daily use. 
Most importantly, MONSTR is an interactive program, which means the 
user can type control-C to abort at any time. The Works Manager, of 
course, is not interactiv' This difference is crucial, because a 
control-C at an inopportu. time can cause the WMTF or IRS to leave the 
database in a locked state, causing all MONSTR users to wait forever on 
an operation. MONSTR version 1.2 went a long way towards correcting 
this problem, but the database is still able to get into a locked 
state. This reflects the fact that the NSW database machinery was not 
designed to be used by an interactive process. 

Another database problem has to do with the fact that the high 
volume of MONSTR transactions, combined with the WMTF’s lack of a 
garbage-collection facility, leads occasionally to the situation where 
MONSTR "runs out of space", and the database must be reorganized before 
MONSTR can be used again. 

To address these problems two steps have been taken. First, a 
number of changes have been applied to the WMTF and IRS (especially the 
former) to bring them more in line with the pattern of use MONSTR 
places on them. Second, a MONSTR operator performs a daily database 
dump to check for a locked database and to have a "copy” of the 
database in case the database must be restored. The latter event has 
only occurred two or three times in seven months. 

Further MONSTR work should progress along a number of fronts: 

0 Database enhancements -- As described above, the database support 
for MONSTR is its weakest link. Modest changes in the Works 
Manager Table Facility will greatly increase MONSTR's overall 
reliability. 

o Operator tools -- Currently the MONSTR operator has four tools: 
MONOPR, a very simple operator utility; and the three database 
simulation tools SIMWMT, SIMWTF, and SIMINF. The latter three 
lack key functions (e.g., printing the status of certain types of 
locks, resetting certain locks, etc.). The MONOPR tool (akin to 
the NSW OPRUTL tool) must be further developed to allow such 
things as STR delation, adding new persons and organizations, 
etc. 

o Addition of sets and working groups -- MONSTR must offer the 

ability to deal with named sets of STRs, sets which can exist for 
the duration of a session and across sessions. When a set exists 
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across sessions, it is generally of concern to a number of people 
who want to comment on the contents of the set. This capability 
we call ’’working groups”, i.e., groups of people who wish to 
discuss some named collection of STRs (e.g. "all STRs to be 
fixed in the next release", "all File System STRs”). 

o User interface changes — The user interface to MONSTR is via a 
collection of terminal handling routines used by the T0PS20 Front 
End. This has led to a slightly clumsy interface, with a lot of 
typing to produce a simple effect. MARGOT, a macro-based 
command-language interpreter-generator, is a tool which could be 
moved to the T0PS20 to provide a more flexible command interface 
to all T0PS20 components (Front End, OPRUTL, LOGUTL, MONSTR, 
etc.) . 
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Appendix 1 -- ANNOTATED TASKLIST 


This Appendix contains our conclusions about the importance and 
difficulty of implementing various of the features proposed in the NSW 
Redesign Study. It is especially directed toward providing a tasklist 
for the next NSW System Release. Appendix 2 will go into explanatory 
detail on the nature and effect of making the changes listed here. 

We are now in the process of planning and designing for NSW Release 
6.0. We currently anticipate the following changes/features to be part 
of that major system release. Task numbers following the enhancements 
refer to the RADC approved task list. Section numbers refer to 
appropriate sections in the accompanying design document (Appendix 2) 
which specifies the details of the new functionality. 

A. Revised and Integrated NSW Resource Catalog Design and 
Implementation; Sections 1-9, this includes: 

o improved and consistent naming, lookup and entry functions; 

o revisions to support single integrated object space, 

including full support for file and service type objects 
(Task ^); 

0 revisions to the definition of semaphores (Task 9); 
o revisions to the scoping mechanism (Task 17); 
o addition of own space automatically created with new nodes; 

B. Decentralized Protocols for NSW File Movement and Service 
Activation (Section 10.1). 

o WM procedures for file/service entry, lookup and access 
control (Task 1); 

o FM procedures for directly participating in file movement 
(Task 1); 

C. Protocol Modifications to Avoid Timeout on Long Operations 
(Task 2) (Section 10.3). 

D. Automatic Cleanup of Old Session on Re-Login Attempt (Task 3) 
(Section 10.6). 
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E. Limited user I/O commands (Task 5) (Section 11). 

o TYPE command to view text file on user's terminal. 

o PRINT command to send that file to line printer (UNIX FE and 
UNIX line printer only for this release). 

F. Extended Services and Service Session Support (Task 7) 

(Section 10.8). 

o standard WS command interpreter (at minimum TOPS-20 TBH); 

o native mode services (at minimum TOPS-20 TBH); 

o limited single host tool kits and chained tools (at minimum 
TOPS-20 TBH); 

o revisions to support direct file access; 

o ICP contact socket tools; 

o detachable service sessions (at minimum TOPS-20 TBH); 

o automated service registration (TOPS-20 TBH minimum); 

o additional parameter collected and passed to the TBH on 
service initiation; 

o character string arguments collected as part of "USE" command 
line; 

o session id, user login name, service name, etc., available to 
TBH service; 

G. Status Commands for the User (Task 11) (Section 10.2, 10.^) 

o ability to view static descriptors of file and service system 
objects, node and session records 

o list of logged-in users 

o status of configuration hosts (use "Inf NSW"?) 

0 dynamic status of a user's active services and long 
transactions 
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H. TBH/WM Data Base Synchronization Improvements (Section 10.5) 

WM comes up -> TBH FM (from config.bas) 

I. Programmable Controlled Communication Between FE-TBH to Support 
Service Sessions, (Section 10.9). 

o selectable TELNET control sequences 

o selectable MSG alarms in place of control characters 
o selectable help alert signals 

J. Other System Changes/Bug Fixes 
o MSG large host-address mode 

0 avoiding user password recording in event logging 
o directly runnable (non-dispatched) TOPS-20 FE 
o TOPS-20 FM using GFT parameters 

o upgrade WM-BATCH-ENDJOB to propagate accounting list 

0 Make WMO batch monitoring capabilities available as a service 
invocable from a TBH. 

0 New BCPL 

0 Additional compiler FE status Queries 
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Appendix 2 — DRAFT SPECIFICATIONS FOR FUTURE RELEASES 


This Appendix contains a November 1980 version of a developing draft 
specification for the changes to be made in NSW Release 6 (plus 
forethoughts about Release 7). The evolving document was originated by 
BBN, as is maintained by them, on the basis of frequent discussions 
with COMPASS personnel. This Appendix includes sections written by 
COMPASS personnel, and has been somewhat modified to reflect changes 
which were agreed to since this particular version was created. Some 
of the detailed specs given here are still subject to modification. 

1. GENERAL FORM OF OBJECT NAME 

The NSW resource catalog supports a single, uniform name space for 
naming all retained NSW objects. Objects are named as an ordered 
sequence of name components, separated by the special character 
It is useful to view an object's name as describing a path through NSW 
name space to the object. A complete pathname refers to a name 
beginning at the implied root of the NSW hierarchical name space and 
uniquely naming a single terminal object through the sequence of 
ordered name components. 


2. KEYS 

NSW access control is based on permissions (capabilities) held by the 
accessing agent. For controlling access to resource catalog objects, a 
permission (a key) may refer to either a single unique object in NSW 
name space, or all objects in an entire region of NSW name space. 

Syntactically we write: 

ABC.DEF.G as indicating a permission referring to the object uniquely 
designated by ordered name components ABC, DEF, and G. The object need 
not exist at the time the permission is created. 

Or ABC.DEF.* as indicating a permission referring to the entire region 
of name space containing objects whose complete pathname begins with 
ABC.DEF. The region is evaluated at each access and includes all 
objects in the region at the time the right is exercised. 

A key may include any number of '*'s, as long as it does not begin with 
one, and no two '*'s are consecutive. Thus the key ABC.•.DE.FG.*.H 
gives access to all names in the catalogue which start with ABC, 
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contain DE and FG consecutively somewhere, and end with H. 

There are different keys for governing different kinds of access 
privilege. Three kinds of keys are defined for reading and writing the 
catalog itself. These keys are: 

o LOOKUP keys, required to do catalog object lookup operations in a 
given region (somewhat equivalent to directory read access on 
some systems) , 

0 ENTER keys, required to create a new object name in a given 
region (i.e. directory write), 

o DELETE keys, required to remove a current catalog object name in 
a given region (a specialized form of directory write). 

These keys are applicable to all catalog operations regardless of the 
type of the object being manipulated. 

Keys are stored with the node record to which the permission applies. 

In addition to these private keys, there is a system table recording 
public keys. Public keys are keys which system administrators have 
determined to be available for all user's of the system. A user's 
rights are determined by the union of his private keys with any public 
keys,. (Public keys are merely a simple mechanism to both avoid 
replication and support convenient update of keys common to all users. 
The regions covered are part of the "system". For now, the public key 
table is modified only via system administrative meansK 


3. OBJECT ATTRIBUTES 

All objects in the NSW resource catalog have attributes including (but 
not limited to) "type" and "site", where "type" is currently envisioned 
to be one of file, device, workspace, or service, and "site" indicates 
the host on which the object resides (site may be a list of locations 
in special cases). Every NSW object must have a unique name 
independent of its attributes. Objects cannot differ only in their 
attributes. Syntactically we can write: 

A.B.C.D/type=device to refer to an object with name A.B.C.D which is 
of type device or 

A.B.C.D.E/type=file;site=ISIE to refer to an object of type file and 
which is stored on host ISIE. 
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4. NAME LOOKUP 

In general, manipulation of NSW resource catalog objects proceeds in 
three phases: 

o name and attribute lookup 
o general disambiguation (optional) 
o typed access control check 

We can view the phases of object manipulation as a process of refining 
the set of objects which meet the specified requirements. Name and 
attribute lookup produces a set of one or more possible objects meeting 
the name and attribute constraints. This set can be reduced to a 
single object via a search rule or user help. This single object is 
the result of the lookup procedure, which is then checked for 
appropriate access control based on the type of object found and the 
type of manipulation requested. 

4.1 FULL PATH LOOKUP 

All accesses to the NSW object catalog requiring an existing object use 
the same lookup procedures, which are as follows for the case where a 
full pathname is specified: 

(1) Verify that some lookup key is inclusive of the full-name 
object specifier) if none, lookup fails. 

(2) Lookup the named object and return its catalog entry handle; 
if no such object, lookup fails. 

(3) If attributes are specified, succeed only if object found has 
the required attributes. 

When referencing an NSW catalog object, a user need not always give a 
full path name for the object. Two mechanisms exist which allow some 
name components to be omitted when referencing an object. The 
mechanisms are: scoping to support relative naming, and ellipses to 
support omitted component names. Object names employing either or both 
of these mechanisms are referred to as object specifiers (or object 
specs, or just specs). 

4.2 ELLIPSES 
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When specifying an object name, the special symbol may be used 

to indicate 0 or more components may be missing from the name as 
specified. Missing components may be before the first specified 
component, between specified components, or after the last specified 
component, with as many instances as required. 

For example: 

A.B...E, meaning 0 or more missing component names between the B and E 
component names. 

A.B..., meaning possible missing component names after the B component, 
etc. 


. . .A.B.C 


...A.B...C.D... 


A...B...C.D...E 

are all legal object specifiers. 

When an object specifier includes ellipses, the areas of NSW object 
space to which the user has lookup keys are searched for possible 
matching entries. The set of matching name entries is then reduced by 
any attribute requirements associated with the lookup; in particular, 
if the lookup specified a certain object type, only names with that 
object type are considered a match. If the set of matching objects has 
no members, the lookup fails. If the set of matching objects has 
exactly one member, that member is used in completing the operation 
(i.e. the operation specific access control check and subsequent 
object manipulation). If the object matching set has at least two 
members, user or program help can be invoked (if requested) to select a 
single member, which is then processed as above. If no help is 
provided when there are multiple matches, the lookup fails as it is an 
ambiguous object reference. 

We refer to a name which includes ellipses as an incomplete name 
specifier, whereas a name which does not contain ellipses is a complete 
name specifier. 

il.3 SCOPING 

The resource catalog lookup function allows users (programs) to 
reference objects relative to user-selectable regions of NSW resource 
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space. These regions which are used as part of the lookup function are 
called scopes. A scope is a sequence of name components that 
designates the region of NSW name space consisting of names beginning 
with the scope's sequence of name components. Naming an object 
relative to a scope is much the same as directory-relative naming 
common on many systems. There is a single collection of scopes for 
each user, which supports all lookup operations regardless of the NSW 
operation being performed (Note 1). Active scopes for a user session 
are initialized from a permanent node record (Note 2). They can be 
modified either permanently in the node record or temporarily in tiiC 
session record. All NSW object specs are looked up using scoping rules 
unless instructed not to by means of an explicit "unscope" request. 

Such a request is made by beginning the spec with the special symbol 

indicating that the name is to be looked up in the context of the 
entire catalog. The convention to be used throughout this document and 
throughout the NSW implementation is that names which begin with a $ 
are relative to the root of the catalog, whereas names which do not 
have a leading $ are relative to the scopes in effect at the time. We 
sometimes refer to a name which employs scoping rules as a partial 
pathname specifier, whereas a name which does not employ scoping is a 
full pathname specifier. Scope regions are specified like keys, except 
that a scope must have only a single special symbol, and only as 

its final component. A scope cannot be incompletely specified (i.e. 
contain ellipses) . 

Note 1: We would like to extend the design to support multiple 
collections of scopes which would be nameable and 
dynamically selectable for referencing NSW objects. 

However, in order to keep things simple for the present, we 
refrain from doing so at this time. 

Note 2: When a new node is created, the scope field in the node 
record is automatically set to the own space which is 
associated with and created for the new node. For example, 
$ABC.DEF.* denotes the scope covering the region of NSW 
object space with initial name components ABC.DEF. 

At any point in time the scoping set for a user can include: 

(a) a single scope region 

(b) a sequence of scope regions in which ordering is important 

(c) a set of scope regions in which ordering is unimportant 
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(b) is referred to as a serial set of scopes, whereas (c) is a parallel 
set of scopes. 

Functionally, scoped lookup (spec does not start with '$') proceeds as 
follows: 

a. If there is a single active scope region in effect, look up 

the spec relative to the scope. This is accomplished by 
replacing the of the scope with the given spec to form 

the full name specifier. Catalog lookup proceeds as 
described in sections 4.1 and 4.2 for names without and with 
ellipses respectively. 

examplel: ifscope=$A.B.* 

and object specifier was C.D, scoped lookup would be 
equivalent to lookup of $A.B.C.D 

example 2: if scope = $A.B.* 

and object specifier was C.D.../type=file, then scoped lookup 
would be equivalent to lookup of $A.B.C.D.../type=file 

example 3: if scope = $A.B.* 

and object specifier was ...C.D, then scoped lookup would be 
equivalent to lookup of $A.B...C.D 

b. If there are serial active scopes, lookup the user/program 
supplied object specifier relative to the first scope in the 
sequence, 

if a single matching object results, the lookup succeeds and 
searching ceases. 

if a multiple matches occur within the single scope, perform 
user disambiguation if provided; if disambiguation succeeds, 
the lookup succeeds and searching ceases; if disambiguation 
fails, the lookup operation fails. 

if no object matches occur within the single scope, get next 
scope and repeat the above steps. 

if no more scopes in the sequence, lookup fails. 
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c. If there are parallel active scopes, look up the supplied 
specifier as above relative to each of the scopes 
simultaneously. Create the set of objects which can be 
looked up with all of those full path specifiers. If no 
matching objects are found, lookup fails. If a single object 
is found, use it for satisfying the operation. If multiple 
matching objects are found, proceed as directed by user help 
to resolve to a single object. Then use it to satisfy the 
operation. If unable to resolve to a single object, lookup 
fails. 

A single active scope is somewhat equivalent to the concept of a 
working directory common to most systems. Serial scopes are a slight 
generalization of search rule lookup, available on some systems. As 
specified here, NSW would support a single, unnamed scoping set, either 
parallel or serial. Obvious extensions would be to have more than one 
(named) scoping set, and/or allow user specifiable combinations of 
serial and parallel searches. 


5. ENTERING CATALOG OBJECT NAMES 

A set of rules similar to those for lookup apply when entering objects 
into the catalog. As with lookup there are various modes for doing 
this: scoped or unscoped names, with or without ellipses. 

Ellipses in the name of an object being entered in the catalog serves 
to indicate that the name is to be "completed" in the context of the 
current catalog using the incomplete name lockup mechanism prescribed 
earlier. Scoped names with ellipses are resolved within the context of 
the current scopes only. Any incompletely specified name can only be 
used to replace an existing object (possibly creating a new version if 
that were available). It can not be used tc create a new object name. 

The catalog enter function which determines the complete name for an 
entry spec is a slightly modified version of the NSW object lookup just 
described, and works as follows: 

Find a set of candidate complete full path object names by applying the 
basic NSW lookup mechanism to the entry spec. 

1. If the resulting set contains a single object, the complete 
name of the existing object is used for the entry operation. 
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2. If the resulting set has no objects then 

0 if the spec contained ellipses the entry operation fails 

0 if the spec was already a full path specifier (i.e. 
beginning with ’$') use the spec as the complete entry 
name 

o if the spec required scoping and there was a single scope 
region, the complete name is the spec appended to the 
scope 

0 if the spec required scoping and multiple scope regions 
are being used in series, the complete name is the spec 
appended to the first scope region 

0 if the spec required scoping and multiple scope regions 
are being used in parallel, the complete name is 
determined by user disambiguation if available; f^lse the 
operation fails 

3. If the resulting set has no objects, the operation fails. If 

the resulting set has multiple objects, perform user 

disambiguation. 

An Enter right to the appropriate region is required as well as a 
Delete right if an object is being replaced, in addition to a lookup 
right. At the catalog lookup level, the type of the object can be 
required to match or not depending on whether the attribute "type" is 
included with the specifier or defaulted by the operation. Actual 
replacement of catalog objects can be confirmed or not based on 
parameters of the operation. For entering new objects into the catalog 
(as with accessing existing objects) the catalog object name phase may 
be followed by type and operation dependent access control checks 
before the operation can complete successfully. 

[It will be important for users to understand that with serial scopes 
their first (or only) scope should include enter rights to allow the 
system to automatically create objects on their behalf (e.g. a 
temporary workspace name, a profile, etc.). Having the system 
automatically find a region to which the user has ENTER access seems 
like a bad idea. Another alternative might be to add the concept of a 
"login" region, as distinct from a "connected" region which scoping 
represents. We do not plan to pursue this further at this time.] 
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NSW 6.0 will employ all of the preceding naming and lookup conventions 
for all catalog operations. In addition, existing user interfaces and 
system commands will be upgraded to reflect the modified operation of 
the catalog software. 

System changes: 

0 Modify WM catalog maintenance procedures to support new naming 
lookup and scoping conventions. 

0 Modify (as necessary) ALL NSW components associated with the user 
interface to support the naming conventions when displaying NSV/ 
catalog names and regions. 

0 Front End commands which must be modified are: 

ALTER (scopes) : to support augmented scope types 
SHOW SCOPES : to remove access type 

SHOW FILES : to remove access type 

0 Modify WM software to support public access regions. 

0 Modify WM software to create private own space with node 

creation . 

0 Add commands for permanently modifying scopes in the node record. 
6. NAMING GROUPS OF OBJECTS 

The name lookup and entering conventions discussed so far are intended 
to identify and name a single catalog entry. At times, there is also a 
need to succinctly name a group of catalog objects (a plural name), 
usually in conjunction with some form of processing common to the 
entire group. The SHOW OBJECTS command is per aps the most prominent 
example of where a designator is often sed to denote a group of 
matching objects instead of being rpsotve t.o a single object. The 
syntactic form of a plural name is e ju i v al e.n r, t.) that of a partial ramt- 
specifier using ellipses, with Lhe exc<.pi..itiuc itie special characte’- 
is used instead of the special cfiainfer to denote objects 

with zero or more missing component it p'a».c tiie We have 

already indicated an important spjcia. r s? of cne naming 

convention when referencing aey ji! . ..y .rgiu.io. a ^cter-l pi ji 1. 
name can have multiple components, iniJding preceding and trci.i'r 

any specified name parts. cari ^pcrar t.l y it the n^itre parr of e 
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plural object specifier. is implied for all unspecified attribute 

fields. The matching set can be reduced by including particular 
attribute values with the object specifier. 

example $A.B.*.C/type=file 

would refer to the collection of file objects to which the user had 
lookup access, which began with component names A.B and terminated with 
component name C. If the name in the example did not have a leading 
the lookup would be with respect to the scope setting prevailing 
at the time. Parallel scoping rules applied to a plural name generates 
a collection of objects which is the union of the plural name applied 
to each scope region. Serial scoping rules applied to a plural name 
generates the set of objects matching the name for,the first scope 
which has a non-empty lookup result. 

example: Serial Scope in effect: 

$A.B.* $A.C.* $A.D.* 

Catalog contains objects {$A.C.E, $A.C.F.E, $A.D.E, $A.B.G}. The 
plural name *.E would refer to the set {$A.C.E, $A.C.F.E}. Had the 
scopes been parallel, the appropriate set would be {$A.C.E, $A.C.F.E, 
$A.D.E}. We defer further discussion of the use of plural names of 
this type within the context of NSW primitive operations. 

NSW 6.0 will use and support plural naming conventions for all keys and 
scopes, and objects referenced with the SHOW command. 

System changes: 

o Mooify WM software to process the new form of plural name for 
scopes, keys and object lockup. 

o Modify WM software and (if necessary) Front End software to 

accept and display plural names in the commands which accept or 
display keys, scopes and sets of objects (currently only SHOW). 


7. ASPECTS OF THE FILE SYSTEM MODEL 

NSW supports a copy model for workspace file processing. WS-CI's 
always make local copies of NSW files to be used for supporting a 
service session. In addition, unless otherwise requested by the 
accessing service, a tool reference to an NSW file will result in a 
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nameable workspace copy of the file. A copy is a snapshot of an NSW 
file at a given instant in time allowing for the possibility of some 
host or service dependent data transformations. The NSW system does 
not maintain tiie mutual consis'-ency of ^copies. Optimizations to 
support read only access where by the file is not actually copied when 
a locally accessible NSW file space image is already available, are 
supported; however the copy s'^mantics must still prevail from the 
perspective of the accessing service. The copy semantics provides 
uniformity across translated ;information lossy) and non-translated 
file movement, and across hosts which do not maintain local NSW file 
storage resources. A tool can specify a read only file access request, 
and to the extent enforceable or believable on the service host, NSW 
TBH Software can make use of an opt! mi non-copy access path to the 
NSW file space image for satisfvine the file ac;esses. The 
optimization has no eff-“ct on tha NSW access control mechanism. 

; Comment : the workspace cop'V model s'^rves as a mechanism for hiding 
some of the problem areas in the fundamental functionality of the NSW 
file system and file system tr'cisfoi capabilities; in particular, lack 
'f host independent access metiiods, some i n f ormat i on -1 ossy file 
transfer modes, and automatic tool-specific file conversions make 
developing an intognated heterogeneous file system very difficult.i 

7.1 FILE IMAGES 

Users can request that an i rife'’■nat i in-i ossless image of an NSW file be 
MOVED from its current NSW storage host to anot'r r NSW storage host (if 
cuc.c a transfer is nc.ssible) . The sv.stem undarstands the equivalence 
of the original physical copv and the new phy.r-ical image. Files 
entered (imported) into NSW file space are always marked as "original." 
Images maintained by the system as a result of a MOVE operation ar“ 
mark'^d as a "us‘-r-riir"''t“d-i.'n='f’‘-‘' " In ociciition, to support the copy 
semantics for worz.spa e file iTTi^v'e- if NSW files are often 

transported from a storage ha^r 'u’^-rtlv .i'.oporti r; a physical copy to 
one whicii needs t-i msa the Ci-io t e i-g occurs, and when the 

destination d'.'-'- ia Ntv F i’■-= F..-a.-i-1^.1 ip-, ■: nat 1 on may 

at its d i s^ ret 1 en r 1 1- 3 1 n an i e f 1,ar i -Ie-1 les1 ess i einc“ (5 f t he original 
o .serve a.s a ''a'hei .^-pv Tm-^rec: a i r. f j j noS tv t o .^vster. a '■pgutt 
'f tool oriented file o-rvement are marked as a "system-d irected-im.cage." 
The rete”. tian of 3 e;,nhp(^ mus‘ be ■'^ordi rated with the cen*r,.;| 

•at 11o g. 
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attribute vl’^en referencing the file. Users alone are responsible for 
managing ii.e. moving, deleting) the disposition of originals and 
user-dir'c•cd images (within allocation limitations, of course). Users 
are "charged" for storage associated with originals and user-directed 
images. The system (the FBH) manages the collection of system-directed 
images that it has decided to cache. A FBH may at any time, assuming 
the proper coordination with the central catalog, delete a cached image 
in accordance with its cache management policies and current file space 
demands. The central catalog process (WM) may also initiate the 
deletion of cached images using the same mechanisms as for supporting 
user deletion of originals. Caching represents an area in which the 
system performance may be tuned; updated file access protocols to 
support FBH file caching are given in a later section. Users are never 




On any lookup operation the user may limit the selection of an image 
through the host attribute. Without a specified host attribute, the 
system may select any image interchangeably. If a particular image is 
specified but unavailable, the operation will fail. Replacing or 
otherwise modifying a file catalog object invalidates all existing 
images of the file. The Delete operation defaults to all images of the 
file. 


7.2 IMMOVABLE OBJECTS 

When entering a file object in the NSW resource catalog (IMPORT, 
DELIVER), the object may be marked as "immovable." Existing files may 
also be subsequently so marked, according to appropriate access control 
and prevailing file state. An "immovable" file cannot be copied using 
NSW operations, nor can an image of it be made at other NSW file space 
supporting hosts. Such a file can be accessed only by services that 
run co-resident on the file host, and only via direct access methods. 

7.3 DIRECT FILE ACCESS 

A service can request direct access to an NSW image of an NSW file. 

Such access can be granted only if: 

o the TBH can support this mode of access without violating the 
integrity of the NSW file system 

o a file image exists in local NSW file space or can be moved to 
the TBH NSW file space (e.g. it is not marked immovable) 
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o the file can be used by the service without any service specific 
transf ormations 

0 appropriate catalog file locks can be set 

0 user/tool has appropriate modify access rights 

If any of these conditions are not met, the operation will fail. 
Granting direct access to an NSW file image invalidates all other 
images of the file, and causes the image which is directly accessed to 
be marked as the original. The NSW does not itself support the 
primitives for file access methods (i.e. for referencing internal file 
data). Direct file access is provided only through existing TBH 
specific file access methods where appropriate. 

File catalog locks must be explicitly or implicitly released when the 
direct file access completes. 

7.4 FILE SEMAPHORES (locks) 

Users/services can request that a "lock" be set on an NSW file to 
control access to it as it undergoes modification. Locks can be set 
for exclusive access, multiple-reader/single-writer access, or as a 
warning, to support alternative patterns of shared access. The 
duration of the lock can be indefinite (until explicitly cleared), or 
can coincide with the lifetime of the setting activity (service, or 
user session) . 

When accessing an NSW file object, the operation proceeds in the 
following phases. First, the name is looked up in the catalog to 
identify the object. Then the appropriate object specific access 
control check is applied. Finally, and only after completing these 
initial phases, any requested locking specification is checked for 
consistency with the current lock state. If the use is consistent, the 
operation can be completed. If not, the operation fails. 

NSW 6.0 will support read only file access, direct file access, 
immovable objects, and full-file semaphore functionality. It will also 
support multiple image file management functions. 

System changes: 

o Support protocol addition 10.2 and and modify the GET and other 
additional parameters. 
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o Augment (if desirable) TBH software to make use of protocol 
additions in support of enhanced file access procedures. 


8. NEW OBJECT TYPES 

In addition to the object type "file" and object type "service" 
(extended from the NSW M.1 type "tool") which are currently supported 
by NSW, device and workspace objects are also to be entered in the 
common NSW resource space. All object types can appear anywhere in NSW 
name space. The system implementation uses two regions $SERVICES.* and 
$DEVICES.* as repositories for generally accessible user services and 
line printer devices. Users may hove their active scopes set to 
reference regions within $SERVICES.* and $DEVICES.* to facilitate 
naming these system supported services and devices. 

However, because these two regions represent important system wide 
functions, we provide special purpose mechanisms to make the expected 
common access patterns easier without unduly burdening the single 
scoping mechanism, or requiring support for multiple named scopes. The 
first mechanism provides for conveniently looking up system wide 
service objects within one or more regions of $SERVICES.*. The 
mechanism is to have the system automatically append in serial scope 
fashion the relevant regions of $SERVICES whenever a sloped request to 
instantiate a service fails to find a matching object. In effect, this 
merely causes the system to search designated system service areas when 
instantiating a service if it cannot be found in the user specified 
areas. It is the scope equivalent to public keys. In a similar 
fashion, operations which specifically refer to using device specs will 
search a public $DEVICES* region, if lookup using user scopes fails. 

The second mechanism provides for the session record containing an 
optionally specifiable default line printer device name which is 
initialized from the node record and can be used in conjunction with 
the PRINT file command. The default line printer would be modifiable 
temporarily or permanently like scopes. Since we are unlikely to 
support anything beyond lineprinters, and since one typically accesses 
only a single line printer, this mechanism should be sufficient for 
quite some time. 

Permanent workspaces (when supported) are cataloged ..nywhere in user 
accessible NSW space at the time of registration. Temporary workspaces 
are automatically cataloged by the system, under a designated name 
entered in the appropriate region according to the user's scope setting 
in effect at the time the workspace is assigned. When externally 
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referencing a file within a workspace, the NSW set file notation is 
used i.e. WORKSPACE-SPEC!WORKSPACE-FILE-NAME, where WORKSPACE is 
looked up under normal NSW name lookup conventions, and 
WORKSPACE-FILE-NAME is interpreted within the host workspace context. 

When interacting with a service within a workspace, the naming context 
is automatically set to be the service workspace itself. There are two 
mechanisms for escaping from this implied "scope": 

An NSW wide convention for specifying names relative to the NSW 
context (where the NSW scoping mechanism previously discussed is 
in effect) . The convention is the use of a leading special symbol 
('"') when entering an object name. This feature may not be 
supported for all interactive services on all TBH's. 

Optional host specific escapes to reference non-workspace objects 
on the native host e.g. <directory> as a workspace escape for 
native mode on TOPS-20. 

NSW 6.0 will support a system wide service region to be used when 
instantiating NSW services. This version will also support a standard 
"unscope from workspace" naming convention. Supported devices will be 
temporarily limited to line printers directly connected to UNIX-FE 
hosts, or TOPS-20 F£ hosts, as devices private to their implementation 
(i.e. directly associated with). 

System changes; 

o Add $SERVICFS.* public region to lookup for the USE command in 
the WM. 

o Modify interactive NSW mode IBH software to recognize and handle 
"escape to NSW" convention. 

o Ado TYPE and LIST commands to FE, defaulting always to users TTY 
and local LPT Qf any); requires protocol change 10.2. 


9. OBJECT TYPE SPECIFIC ASPECTS OF THE RESOURCE CATALOG 

Although all object types are entered into a common name space, and are 
'■eferenceable via a common mechanism, there are object type specific 
operations, permissions, etc., which have meaning only when referencing 
an appropriately typed object within an appropriate operation. (In 
some cases, operations and permissions may be defined over more than 
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one object type). In this section we attempt to enumerate a minimal 
set of operations and permissions for the anticipated NSW object types. 

Note; the lookup, enter and delete permissions refer to the name space 
itself, regardless of object type. 

For initial implementation, permissions to create and delete specific 
object types are subsumed by general catalog enter and delete 
permissions. Further control is provided by type dependent permissions 
governing the use of the cataloged objects. 

Object Type = File 

Appropriate Permissions: 

COPY: access required to read a file and/or make a copy of it 

UPDATE: access required to change the contents of an NSW file 

object (either through replacement, or direct 
read/write access) 

Appropriate Operations: 

(these operations default their object type attribute to "file"). 

COPY 

RENAME FILE 
DELETE FILE 
GET/DELIVER 
LOOKUP FILE 
ENTER FILE 
IMPORT/EXPORT 
SHOW FILES 

SHOW DESCRIPTOR OF FILES 
MOVE 


Object Type = Service 
Appropriate Permission; 

EXECUTE; access required to instantiate the service 
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Appropriate Operations; 


(These operations default their 
USE 

SHOW SERVICES 

SHOW DESCRIPTOR OF SERVICES 
LOOKUP SERVICE 
ENTER SERVICE 
RENAME SERVICE 

delete service 


object type attribute to "service"). 


Object Type = Device 


Appropriate Permission; 

APPEND; access required to print a file 
Appropriate Operations; 

(These operations default the object type attribute to "device") 

TYPE 

PRINT 

SHOW DEVICES 

SHOW DESCRIPTOR of DEVICES 


Object i'ype = Workspace 
Appropriate Pe-nission; 


ACTIVPTE: acccs. required to instantiate a service in a 

Sorispa^riniiTf- ‘-P-ar, p^mlsslon for the 
workspace is added to the node record for each N'^w 

workspaces assigned to the user as a reLaTof 
invoking a service. result ot 

Appropriate file permissions govern access tn t-ho i 

external manipulation via set file notatiL! workspace files for 
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Appropriate Operations: 

(These operations default the object type attribute to "workspace"). 

SHOW WORKSPACES 

SHOW DESCRIPTOR OF WORKSPACES 

ACTIVATE 


OBJECT INDEPENDENT OPERATIONS: 

Some operations can be invoked uniformly across all object types. 

These operations do not default the type attribute, and include: 

SHOW OBJECT 

SHOW DESCRIPTOR OF OBJECT 
DELETE OBJECT 
RENAME OBJECT 

NSW 6.0 will include full support for object types file and service. 

It will also include support for object independent operations as they 
pertain to files and services. Generalized workspace and device object 
support will be deferred until Release 7.0. 

System changes: 

0 Add object descriptors for service objects. 

0 Add a set of commands which support services in a manner similar 
to file, e.g., SHOW services; Rename services, etc. (in addition 
to existing USE command). 

o Add/modify support for keys of TYPE COPY, Modify (files) and 
Execute (services), including in ASSIGN-RIGHTS. 

0 Add commands to support SHOW Descriptors of files and SHOW 
Descriptors of services. 

o Add command to support Register Service objec 


10. PROTOCOL CHANGES TO SUPPORT NSW RELEASE 6 
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In this section, we propose a number of protocol changes to support the 
file system enhancements mentioned, and promote other architectural 
enhancements to be included in the next major NSW system release (NSW 
6.0 which is to include catalog reorganization, WS-CIs, non-FP file 
manipulation, file transfer timeouts, etc) 

10.1 FILE ACCESS 

The following three new WM calls are intended to support 
decentralization of the file access and file catalog update procedures. 
The primitives are to be used to support the inclusion of file access 
capabilities in Foreman components, and to allow FE's access to the NSW 
file system. The implementation approach illustrates an architectural 
trend whereby the WM is used for catalog lookup and access control, but 
the object manipulation is moved closer to the requesting agent. The 
addition of this functionality is completely backward compatible with 
the current file access protocols. The form of each primitive is 
identical, grouping the parameters into process identification data, 
exception handling data, logical object data, and (if appropriate) 
physical object data. 

10.1.1 ENTER-FILE-OBJECT 
Accepts: 

Identification: session id or service id 
Exception 

Handling: help process 

: disambiguation control parameter 

; confirmation control parameter (what to 
do if there already is an object by this 
name i.e. use help confirmation); 

Logical: file specifier (subject to complete name 

lookup rules; fully or partially 
specified;) 

: attribute list for the new object; some 

attributes cannot be set from this list 
(e.g. time of creation) and are 
automatically inserted by the WM; 
attributes include possible marking as 
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immovable object; attribute type=file is 
implicit with the primitive; 

: lookup hint 

Physical: physical file descriptor (for the new 

object in NSW file space); 

: gft 

: size of file (bytes + byte size) 

Returns: 

Confirmation: success/failure 

Logical: full path name object was put away as 

: scope (region) which was used to create 

new entry (if any) 

: lookup hint 


NOTES: 

The Enter-File-Object primitive is intended to support the catalog 
update part of the DELIVER (IMPORT) operation by processes within the 
"security kernel." Attribute type=file is implicit with the primitive. 
Requires enter access + update access if actually replacing a file. 
"Identification" will generally be service id. 

gft and gfd are copied from existing WM/FP primitives and could 
possibly be subsumable by an attribute. 

"help process" is one of: 

(a) the calling process 

(b) process designated as controller from the session record 
(usu 91 iv the FE) 

(c) an arbitrary process id 
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(d) no help process 

Disambiguation control and confirmation control are parameters for 
allowing the calling process to control the use of help messages for 
ambiguous file references and operation confirmation. Both the full 
pathname of the object created and the scope (if any) which was 
actually used to create the full pathname are returned to support 
flexible service use of these individual name parts. 

LOOKING AHEAD SOMEWHAT 

At some point in the near future we are likely to try to support a 
modified form of the DELIVER scenario in which a component on a 

non-File Rearing host (e.g. UNIX FE) can directly provide a copy of a 

local file for inclusion in the NSW file system. We anticipate further 
modification to the Enter-file-object primitive to support this 
capability in the form of an extended PCD parameter. There seem to be 
two possible approaches. One is to have the PCD refer to a connection 
ID on which the donating process (i.e. the FE) is willing to send the 
appropriate file when requested by a SEND-ME message from a FP selected 
by the WM. The other is to have the FE component first interact with 
an FP on a FBH (which FBH is an issue here) , and then have the PCD 

returned with the Enter-File-Object refer to the FBH copy. We defer 

further design on this topic for now. 

10.1.2 ACCESS-TO-FILE-OBJECT 

Accepts: 

Identification: session id or service id 
Exception 

Handling: help process 

: disambiguation control parameter 

(including how to handle lookup failure) 

: confirmation-control parameter 

Logical: file spec (subject to general lookup 

rules); 

: attribute list (those attributes,if any, 

which are to be used as disambiguation; 
attribute type = file is implicit with 
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the primitive); 

: access type (copy, direct); 

: locking data (type, duration); 

: lookup hint (optional) valid only with 

full file name specifier; see note below; 

Returns: 

Confirmation: success/failure 

Logical: full NSW file name of object looked up; 

: scope employed to locate object (if any); 

; attribute list including creation 

timestamp, or version (if we ever support 
that); 

: new file specifier (if any was obtained); 

: lookup hint (optional; can be ur-r' •; th 

any future reference to the file ou. ect; 
see below); 

Physical: physical file copy list (including a 
marked original) gft gfd 

NOTES: 

The Access-to-File-Object .primitive is intended to support the catalog 
lookup and access control check part of a file access procedure. It is 
intended that the FE or FM process use the returned object descriptors 
to interact directly with the appropriate FP to obtain a copy of the 
file (or access a local copy if accessible). When invoked from a FF, 
identification will typically be session id; from a FM, identification 
will typically be service id; alternatively, {user n-tnp + password] 
strings can be supplied as authentication data. 1; j :• case, a pseudo 
user session, lasting for the duration of the operation is created. If 
password is omitted, it can be obtained via user help, as specified. 

The file specifier and any listed attributes are used as augments to 
the lookup function. If a single object results, the access is checked 
based on the access type requested. If the accessing agent has the 
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appropriate permission, the locking data is checked for consistency 
with current usage. If {user + password} authentication is supplied, 
only indefinite duration locks can be set. A failure at any of of 
these steps results in a failure of the operation except for the case 
where lookup results in an empty set and the caller has requested via 
the disambiguation control parameter that the system gather an 
alternative file specifier (as requested by UCLA). In conjunction with 
this new primitive, each FP on every FBH must be modified to accept 
file movement requests from non-WM kernel components (if they do not 
already do so) . 

When this type of request is issued by non-kernel (FE) processes, 
additional authentication messages may be required to achieve a secure 
system. Alternatively, it seems possible to develop a scheme whereby 
for non-kernel processes the Access-to-File-Object returns an encrypted 
capability which can be presented to and validated by the appropriate 
FP for retrieving the file. This approach would not change the pattern 
of communication for non-kernel processes, but would introduce 
additional authentication overhead in all of the components. We defer 
further consideration of system security at this time in order to 
introduce new functionality without requiring system wide changes. 

LOOKUP HINTS 

The lookup hint is a means whereby the WM can provide an internal 
handle for a catalog entry in the WM data base to another NSW component 
when an object has been looked up in the catalog. The form of the hint 
might be an internal catalog identifier or virtual memory address. The 
idea is that when and if that object is subsequently subject to another 
lookup operation, the hint may provide a more efficient path to the 
appropriate catalog entry than would be the name specifier. Properties 
of the hint mechanism are that it is never required, and the lookup 
will logically yield the same result whether or not the hint was used. 

"he motivation for including a lookup hint type of param.eter at this 
time is to solve the following problem related to supporting autonomous 
File Bearing Host (FBH) based file image management. By separating the 
file name lookup transaction from the physical copy manipulation 
transaction, we have also effectively removed the WM from the reply 
loop for indicating that an additional NSW file image is being retained 
at the FBH (in the case of an inter-host file reference). When the FBH 
software decides to cache a file image after an inter-host transfer, 
the pti>sical descriptor data must be reported back to the WM for 
inclusion in the catalog so the image can be used to service subsequent 
references to the I'ile. 
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There seem to be two ways to do this: 

(a) conditionally including two additional specifically 
addressed messages (cached image data and confirmation) 
with the definition of the access-to-file transaction; or 

(b) defining an independent file-image-update transaction 
which can be generically initiated when and if the cached 
image is retained; 

The problem with the first approach is related to the decentralization 
of the caching decision. Since the decision is made by the FBH 
component, it must alert the WM of its intentions to cache an image 
along with the request for lookup so that the WM will continue the 
transaction beyond the reply to the lookup. This is made a little 
tricky since the desire to cache is predicated on there being a 
transfer to begin with. That decision lies with the referencing 
component and may not be made until it views the PCD list. We reject 
as too error prone an extended transaction based on characteristics of 
the FBH caching implementation matching against the PCD list returned 
to it. A scheme v.'hereby the WM always waits some time out interval for 
a possible additional reply is also feasible, but would seem to be 
adversely effected by high load situations under which caching might be 
all the more important. 

The problem with adding an independent file-image management 
transaction seems to be the high overhead of recreating the context for 
referencing the file in question at the catalog. One important use of 
a continuing specifically addressed transaction is that the context 
associated with handling the particular operation is maintained within 
a (WM) process state or "hot" data base entry, and need not be 
recreated with each phase of the activity. Generic message sending 
does not seem to be significantly more expensive than specific message 
sending. Also, the current inter-message processing interval is very 
large relative to internal virtual memory management intervals, so the 
appropriate pages and memory maps will likely be swapped independent of 
whether it is handled by a single continuing process or an independent 
process. The major impact of an independent transaction is expected to 
be the replication of the name to object lookup for processing the 
independent parts of the "logical" transaction. To alleviate this 
overhead, we intfoduce lookup hints as arguments returned when an 
object is looked up. That hint can then be optionally supplied as a 
subsequent transaction parameter to optimize access to the same object. 
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Some proposed details of lookup hints for the catalog object update 
operation: 

The hint itself is uninterpreted by the component which receives 
it; it is merely remembered and returned when the same object is 
to be referenced. 

- When using a hint, only a full complete pathname is acceptable 
(i.e. including $ and no ellipses) for the file specifier. 

There are two somewhat distinct uses of hints which can be 
supported. In one case, the reference is to any version of the 
object in the catalog under the complete name. In this case, no 
further name qualifier is required. A second case is where only a 
particular version of a catalog object can satisfy the request 
(e.g. for reporting a new image of an existing version). To 
support this second case, there must additionally be some 
parameter by which the WM can validate that the object currently 
in the catalog under that name is the one to which the hint 
refers. Version numbers would appear to be suitable here, if they 
were part of our system. In their absence, we suggest using the 
object creation timestamp attribute (already maintained in the 
catalog) as the validating parameter. This would mean that 
whenever lookup hints are given out, the creation timestamp must 
be returned as an object attribute. When a lookup hint is used 
and intended to identify only a specific version of an object, the 
object specifier must include this attribute. If the lookup hint 
fails to refer to the object identified by the spec and any 
included attributes, the hint is ignored. If the catalog no 
longer contains an object with that name and those attributes 
(e.g. the version has been replaced), the operation fails. It is 
intended that the file-image-update operation include the creation 
(version) attribute, and that the operation fail if the object it 
is updating is not the one to which the hint applies. This is 
what would normally happen if the name and creation attribute did 
not match the current catalog entry under that name, even without 
the hint. 

The same hint and name specifiers wouid be usable for subsequent 
FBH to WM catalog updates to indicate that a cached image is to be 
deleted. 

The primitive for initiating the transaction to add or remove cacned 
file images from the catalog data base (used by "security kernel" 
processes) would be the following: 
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10.1.3 FILE-IMAGE-UPDATE 
Accepts: 

Identification: service id; 

Exception 

Handling: none 

Logical: full file name specifier (only); 

: attribute list (must include creation 
timestamp); 

: lookup hint (optional, from a previous 

reference to the file object); 

: type (add or remove a cached image PCD); 

Physical: PCD to be added or removed; 

Returns: 

Confirmation: keep it, or discard it (default on error 
condition or timeout is to retain with 
the option of retrying a removal at some 
future time); 


NOTES: 

The File-Image-Update primitive is intended to support the coordination 
of independent file cache management by FBH hosts with the maintenance 
of a central catalog of physical file images. It is anticipated that 
the addition of images to the cache would be handled by the component 
coordinating the individual inter-host file transfer (e.g. FM or FP), 
whereas removal might be the responsibility of a background file space- 
management daemon process which periodically purges unreferenced 
images. 

These are the primitives that NSW host components mu^t use to support 
read only file access, direct file access, system directed file 
caching, optimized NSW file copying for service support, and other file 
movement related aspects of Release 6.0 functionality. 
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System changes: 

o Add these new primitives to WM. 

o Write TBH/FE software to use the new primitives for interfacing 
to tool file requests/delivery, and FE file manipulation 
commands. 

o Augment WM-GET, WM-DELIVER to include additional parameters 
needed for controlling file system modifications. 

10.2 CHAINING TOOLS IN EXISTING WORKSPACE 

We propose adding an additional lookup primitives of this time to 
support a form of tool chaining. The Access-to-Service-Object 
primitive would be a call on the WM to perform lookup and access 
control for an NSW service, in much the same way that 
Access-to-File-Object looked up NSW catalog files. 

Access-to-Service-Object would return a service descriptor, much like 
Access-to-File-Opject returns a file descriptor. We envision that a 
Work space command interpreter would be able to use such a primitive to 
support a command for chained services in an existing workspace. At 
this time we anticipate this form of access to service to be able only 
for co-located services. 

10.2.iJ ACCESS-TO-SERVICE-OBJECT 

Accepts: 

Identification: session id; service id; or {user + 
password}; 


Exception 

Handling: help process; 

disambiguation control 
: confirmation control 

Logical: service spec (subject to general lookup 

rules): 

: attribute list (implicit type = service; 

site r expected to be same as requestor); 
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: access type (execution); 

: lookup hint 

Returns: 

Confirmation: success/failure 

Logical: full NSW service name of object looked 

up; 

: scope used (if any) to locate the object; 

: lookup hint 

Physical: physical service descriptor from catalog 

(similar to what gets transferred with 
BEGINTOOL TRANSACTION). 


NOTES: 

Service object lookup is performed in exactly the same manner as file 
object lookup. Once an appropriate object is identified, the accessing 
agent requires an execute key for the operation to succeed. 

10.3 AVOIDING TIMEOUT ON LONG FILE TRANSFER 

To avoid possible transaction timeout by initiating or intermediary 
processes due to an unexpectedly long event, such as transferring a 
large file under heavy load, we introduce the concept of a partial 
reply for long transactions. Transactions are designated as short, or 
long. Long transactions are those that may have a large variance 
beyond the expected variance of message transmission and simple 
processing. Currently, only interhost file transfer will be defined to 
be a long transaction, although others may be so designated as the need 
is identified. For long transactions, we break the replies into two 
phases: the first phase reply is an intermediate status response 
indicating only that all of the resources (hosts, processes, files, 
etc.) needed to complete the transaction are both currently available 
and committed to this transaction; the second phase reply is the normal 
termination of the transaction as currently supported. (See section 

10.4 for a discussion of status querying during the second phase of a 
transaction). The responsibility for initiating the first phase status 
reply lies with the last process in' oked in any designated long 
transaction chain. This process ir identified in the documentation for 
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each relevant NSW scenario. Status replies are sent to the process 
designated in the invoking message as the one to which completion 
replies are to be sent. This is a process which is presumably timing 
out a final response, and is usually the invoking process. 

It is the responsibility of all intermediary processes in a designated 
long transaction to relay (and possibly enhance) the status reply back 
to any process which may be awaiting its final response. (In some 
cases, a message serving as a status reply may already be part of the 
scenario). The issue in selecting and limiting those transactions 
which require intermediate status replies is one of avoiding the 
additional overhead in those cases where the status reply mechanism is 
of the same order of processing magnitude as the operation it is 
reporting. In general, an intermediate status reply should be 
acceptable (but not required) for any transaction using NSWTP 
conventions. For NSW version 6.0 we will specify and require its use 
in only the single case of file transfer to remedy the obvious system 
deficiency. 


The immediate application of the status reply protocol will be in the 
case of NSW network file transfer. The transfer scenario involving 
network transmission would be upgraded to be: 




Messages marked as "-G" are generically addressed. Messages marked as 
"-S" are specifically addressed. The message marked as is not 

currently an MSG message at all but rather an explicit data 
transmission over the direct connection between the FP processes to 
support the file transfer. It is a optimi'^ation of sorts, to 
incorporate existing signals which serve other functions as well 
(messages ^ and 7) into the general transaction protocol sequence. 

By adding an intermediary status reply which cascades over all of the 
processes of the transaction, we accomplish two things (a) we provide 


- 96 - 















NSW Final Report for the Period Ending December 1980 


some relatively immediate feedback that the operation can be initiated 
and will proceed subject to loading factors on the hosts and the 
network (b) it provides initiating processes with the specific address 
of their generically addressed counterpart; this specific address can 
then be used to initiate further status queries, as discussed in then 
next section. 

TIMEOUTS 

Associated with the two phases cf response for long transactions are 
two sets of timeout intervals. The short timeout interval (the one 
generally in use now) is intended to protect against waiting too long 
Hying up resources) before deciding that the operation is not likely 
to complete because of resource unavailability; the long timeout 
interval is a low overhead approach to protect against failure during 
an operation while allowing adequate time for operations to complete 
under variable load and size factors. A component would commit to the 
larger timeout because it has the prior knowledge that the operation 
has been successfully initiated, and the knowledge of the relevant 
operational parameters (e.g. size of file). 

In general, a component in direct contact with the user can set very 
liberal timeouts provided the user is not locked out during the waiting 
period. If the user is prevented from any other parallel activity and 
from forcing the timeout to occur (i.e. aborting the operation) a 
shorter timeout interval, along with user help for renewing the timeout 
wait, seems advisable. A more complete solution to the timeout problem 
might include lower level guarantees of expedient delivery of timing 
signals. We will not pursue such an approach for NSW at this juncture. 
Rather, we will augment the intermediate response scheme with a general 
user oriented facility which allows one process to "poke" another 
process for its current status, given it has a specific address for the 
process. We will require that a long timeout be renewable if the 
communicating process responds to a status probe sent on expiration of 
the timeout period. This response will indicate that the component is 
still working on the request and that timeout may be premature. 

NSW 6.0 will support the modified protocol which includes intermediate 
replies for all scenarios which have an NSW inter-host file transfer 
operation as a subscenario. This includes the IMPORT, EXPORT, GET, 
DELIVER, COPY. The FP processes are responsible for initiating the 
intermediate response at the minimum whenever a network file transfer 
is invoked. WM processes are responsible for relaying an intermediary 
response back to the original caller (FE or FM). In the case of direct 
FM/FE involvement with file transfer, there will not be an intermediary 
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WM, and the FM/FE will be the direct recipient of the intermediate 
reply. Processes receiving an intermediate reply must remember the 
process name associated with the reply (identifying the next process in 
the chain), and must attempt and be unsuccessful in a direct status 
probe (see next section) of that next process before completing a 
self“initiated transaction timeout. User interface software will be 
modified to confirm self-initiated transaction timeout. 

System changes: 

0 Augment FP's or all TBH's to send intermediate responses. 

0 Modify WM to record intermediate response parameters and pass on 
to original caller. 

0 Modify FE/FM/WM processes to initiate direct status probe 

whenever self-initiated timeout of transaction occurs, and the 
specific name of the process working on the transaction is known. 

The form of the intermediate status responses is: 

send specific () 

need new message type here??? 

10.4 DISTRIBUTED "ARE YOU THERE" 

To allow FE users the ability to interrogate the status of long 
operations and on-going tool activity, we are specifying a status alarm 
to which all WM, FM and FP processes are expected to promptly reply 
with an indication of their current status. There are two forms of the 
status alarm. One form (direct status) requests the current status 
only of the receiving process. The other form (chained status) 
requests the status of an on-going transaction, and may involve 
processes relaying the status alarm to a process which it invoked as 
part of the transaction. A process receiving such a transaction alarm 
which is in the midst of a subtransaction with another process (e.g. a 
WM waiting for a file operation to complete) passes the status alarm 
down the transaction chain to its terminus and returns to the caller 
status derived from the process terminating the chain. This chain of 
events is similar to that for handling intermediate responses, except 
that it is invoked from the source instead of from the terminus. 

We envision the user interface to such a facility allowing users to 
initiate "are you there" alarm signals directed at active service 
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sessions and active long transactions which have already reported 
intermediary status. This would be in addition to the local "are you 
there" (''T) now supported directly within the FE process. Users and 
NSW processes would be able to select either the direct or chained type 
of status invocation. 

The reply to a status alarm serves two purposes; 

(a) it serves to indicate that the appropriate processes are still 
active and (b) it provides a user text message indicating the current 
state of the transaction (to be defined later). Users may invoke "are 
you there" requests to verify that an on going long transaction is 
still progressing. System components may automatically invoke "are you 
there" signals (with a short response timeout) before initiating 
timeout procedures when a long timeout is about to expire. 

Status replies which arrive after a final response to a transaction can 
be ignored. Status probes which refer to an unknown transaction return 
an indication of this condition. 

Specifications for the form of the alarm and its response will be 
forthcoming. 

NSW 6.0 will support a user initiated status probe against all active 
NSW service session and all active long transactions (i.e. those that 
have reported intermediate status). There will be FE commands/control 
sequences for initiating direct and chained status probes, and for 
reporting the results of the probe to the user. 

System changes: 

o Add FE commands/control sequences for status probe initiation 

(direct and chained), and facility to display results (similar to 
help message handling). 

o Upgrade all NSW components (WM, FM, FP) to respond to a direct 
and chained status probe. 

10.5 Other User Oriented Status Commands 

NSW 6.0 will support commands for displaying tool and service object 
descriptors (or at least a subset of the data contained in those 
descriptors). The commands are SHOW FILE DESCRIPTORS, SHOW SERVICE 
DESCRIPTORS, and SHOW OBJECT DESCRIPTORS. Each takes a set of singular 
or plural object specifiers, and displays in text form the relevant 
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parameters of the descriptors (providing the user has appropriate 
access to the object in question). The SHOW NODE command will be 
augmented to display all appropriate node data, and a show session 
command will be added to display all pertinent data associated with 
current NSW user session data base. NSW 6.0 will also support new 
commands (SHOW USERS, SHOW HOSTS) for displaying a list of currently 
logged in users, and a list of hosts which are currently part of the 
NSW configuration at the time. 

10.6 TBH/WM DATA BASE SYNCHRONIZATION 

Currently, when a TBH restarts, the reliability scenarios call for it 
to report to the WM only new LND saved sessions (i.e. those not yet 
confirmed by the WM) which are rerunnable, and those recent sessions 
which the FM is discarding because they are not rerunnable. As 
currently formulated, the WM-LND-SAVED primitive will accept either a 
single tool-id or a list of tool-ids. In either case, the list is 
assumed to be incremental i.e. is in addition to whatever saved 
sessions are already in the data bases. This has led to situations 
where data base entries stored in one data base (e.g. WM) but not in 
the other (e.g. FM) required manual periodic deletion since they were 
not useable and were unreportable as deleted. In addition, hosts which 
did not save any sessions across TBH restarts had no simple way to 
automatically clean up invalid WM data base entries. 

The modification we propose for NSW 6.0 is to add a saved session 
synchronization form of the WM-LND-SAVED call to allow a TBH to report 
ALL of the saved sessions it knows about (or is willing to save) at 
once, including those previously confirmed as rerunnable by the WM. 

This would allow the WM to purge its tables of all entries which the 
hosts have not indicated a willingness to save and are thus effectively 
useless. On completion of this transaction, the WM and TBH service 
session data bases should be synchronized. In particular, this form of 
the LND synchronization transaction will be required at TBH restart 
time. A host that does not support rerunnable sessions will report no 
saved sessions, and the WM will purge all current service activation 
records for that host. 

There will now be two WM functions to support workspace reliability 
scenarios, WM-LND-SAVED and WM-LND-SYNCH. The WM-LND-SAVED message 
provides only for an incremental update to the WM's tables. Both the 
single-session and multiple-session variants of WM-LND-SAVED for 
continued use by an FM implementation. A new protocol message 
(WM-LND-SYNC) is provided for complete resynchronization of the FM and 
WM tool session data bases. The intent is that the WM-LND-SYNCH be 
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used at a minimum whenever the TBH restarts, and that the WM-LND-SAVE 
may be used during normal operation of the system to report isolated 
(e.g. single service session) updates without requiring a full 
resolution of the TBH database. 


WM-LND-SAVE; 

list: ( string: HERALD 

list : (integer: TOOLID...) 
list : (integer: TOOLID...) 

) 

After the FM herald, the first list is of TOOLID's of tool sessions to 
preserve, the second list is of tool session to discard. Either list 
may be null. The most typical case called the single-session case, 
occurs when only one list is non-null, and contains only a single 
TOOLID. It is typically used to handle failures relating to a sir;gle 
tool instance (e.g. a broken FE connection) without incurring the 
overhead of a complete TBH data base scan. 


<reply>; 

list: (integer: TOOLID...) 

The reply is a list of "exceptions.” These sessions are unknown to the 
WM or have been previously discarded. Their entries should be 
discarded by the FM. Should an entry appear on both tlie "preserve” and 
"discard" lists of the WM-LND-SAVED message, the WM shall discard the 
session. 


WM-LND-SYNC: 

list: ( string: HERALD 

list : (integer: TOOLID...) 

) 

The list of TOOLID's specifies the entire set of rerucnable tool 
sessions known to this TBH FM. By implication all other sessions 
associated with this TBH should be discarded. Up to about 50C session, 
may be specified in a single MSG message under current size 
limitations. This primitive must be invoked by each TBH on ev?ry TBH 
restart. 
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<reply >; 

list: (integer: TOOLID...) 

The reply is a list of exceptions which the WM instructs the TBH to 
discard. 

10.7 AUTOMATIC CLEANUP OF EXISTING SESSION RECORD ON RE-LOGIN ATTEMPT 

This protocol modification is designed to support the ability to have a 
user request that an old inactive session activation record in the WM 
data base be purged so that a new login request can be processed. In 
addition this protocol change should support a way to transfer the 
service context from the old session to the new one. This will be done 
through the LND saving mechanism already implemented in the current 
system. 

There follows a discussion of the changes to NSW 5.0 required to allow 
users to assert their right to clean up (in the SAVE-LND sense) a Node 
record which indicates a session in progress, and to effect a new Login 
to that Node. 

User-Interface changes: 

Instead of seeing an FE error-printout of the WM’s text "Somebody 
is logged in to Node <pro j>+<node>’', the user will see a message more 
like: 


NSWExec records indicate that <proj>+<node> is occupied with a 
session which started at <timestamp>. Type CR to save that session and 
continue your login, or ''X to abort the login. 

Assuming the user types CR, his login will complete as usual; if 
there were in fact running Foremen with LNDs to save from the previous 
session, the user will see — probably after some minutes -- messages 
announcing the RESUMEability of those saved sessions ("Records are 
available...”) . 


Front-E:id changes: 

The WM will send an Alarm to the FE, with a code indicating 
that it should do a Stopme, without sending any other messages or 
waiting for any replies. If the FE chooses not to accept this alarm, 
it will become disconnected from all its pending tools, and become 
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unknown to the WM (its Sessid (user id) will no. longer retrieve a valid 
Active User Entry) . 


Data-Base changes: 

+ Include an NSW-timestamp element in Node records and Active User 
entries. This allows the printout mentioned above, which helps 
the user recall whether the wedged session is actually one he had 
trouble with, or is someone else actively logged into the node. 

It also permits the normal LOGIN reply to give the time of last 
login, which is a small, but interesting security datum. 


Protocol changes: 

+ New FE Alarm command, mentioned above. 

+ Foremen should be able to accept an FM-SAVE-LND call from Works 
Managers, as well as from FEs, and send their reply back to the 
sender, of course. 

Foremen need not change their present practice of sending 
Generic WM-LND-SAVED messages during the SaveLnd scenario. 

The fact that some other instance of the WM will receive and 
process those messages is logically irrelevant, and will in 
fact simplify the modifications of the WM code. 

- As a future optimization, the Foremen might notice that the 
sender is a WM, and in that case, include the information 
they usually send in the Generic WM-LND-SAVED in their reply 
to the WM->FM:FM-SAVE-LND call, and skip the Generic WM call. 
We aren't ready to specify the form of that yet, since it 
would involve looking somewhat further into the WM code than 
we have done so far. 


Works Manager changes: 

+ At the outermost block level of the routine Wmlog, declare a flag 
to indicate peremptory overlogging, and space to contain the 
necessary information from the apparently-busy Node record and 
from the corresponding AUE, if available: At least Sessid, FE 
Process name. Semaphore list. 
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+ After the LOGIN parameters have been validated, and the user's 
Node record has been retrieved, the Sessid field 
(N0DE>>node.ndsessid) is tested -- around line 139 of 
WMLOGS:Wmlog. The present code makes an error exit; it should be 
changed to set the overlogging flag, record the Sessid, and try 
to retrieve the AUE for that Sessid. If it can find the AUE, it 
should copy the essential information (or make a local copy of 
the whole AUE) and delete the old AUE from the Data base. Then 
it should return to the present code, setting up a new AUE. 

+ Before writing the new AUE into the database, test the 

overlogging flag and, if set, append to the list of files with 
semaphores set (which has just been copied from the Node record 
into the new AUE) the names of any such files which were in the 
wedged AUE and are not already on the list. (Around line 177) 

+ Return to the present code through sending the WM->FE:Reply (to 
the FE->WM:WM-LOGIN call). Then, before sending the 
WM->FE:FE-LND-SAVED calls for the old tools found in the Node 
record (around line 208), test the overlogging flag, and if it is 
set, generate a list of all ToolIDs which have the saved (wedged) 
Sessid as their user’s id (using the Wmtess - Tfrrtv technique 
illustrated at lines 399-401 of WMLOGS:Wmflgo, for instance). 
Then, for each element of that list: 

- Fetch the Active Tool Entry for that ToolID to verify that it 
is (still) "active" and still points to the Sessid in 
question; 

Construct WM->FM :FM-SAVE-LND call to the Foreman process 
named in the ATE; close-and-unlock the ATE (so that the 
WM-LND-SAVED code can get at it); send the message, and wait 
for the reply. Not much can be done with the information in 
the reply, even if it is an error-reply. 

Repeat the above steps (“or the next ToolID on the list, if 
any. 

+ Then continue the remainder of the present code in Wmlog, sending 
WM->FE:FE-LND-SAVED messages for the older tools which had been 
in the Node record when it was originally fetched. (The normal 
processing of the FM->WM:WM-LND-SAVED messages will have caused 
WM->FE:FE-LND-SAVED messages for these newly-saved tools to be 
sent, already — presumably these are of greatest interest to the 
user. ) 
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+ Send the above-mentioned MSG Alarm to the FE Process named in the 
wedged AUE. 

+ (Consider subroutinizing — or replicating -- the appropriate 
portions of the code in Wmlnds to accept the FM->WM:WM-LND-SAVED 
information in the reply from the Foreman to the 
WM->FM:FM-SAVE-LND message, for future speeding-up.) 

10.8 DETACH SERVICE SESSION 

This protocol addition would allow a Foreman to request that a service 
connection be smoothly terminated, as if the session had ended but 
without the tool termination interaction with the WM which usually 
accompanies a message ending the conversation. The intent here is to 
allow a WS-CI on a TBH which provides rerunnable Service Sessions to 
support a SAVE command. When available, this command instructs the 
WS-CI to save the workspace context so that it may be resumed 
(reattached to) at some latter time. The current reliability scenarios 
support all phases of this except for the smooth cessation of the 
session without invalidating the session record. The FM can use the 
single tool instance of the LND save function to perpetuate the service 
session record. However, currently, the FM can not break the 
connection to the FE without invoking error recovery procedures (if it 
unilaterally breaks the connection) or invalidating the service entry 
with the WM (if it sends an End-tool message.) 

The new FE function is: 

<<to be supplied>> 

10.9 WORKSPACE COMMAND INTERPRETERS and GENERAL SERVICE SUPPORT 

NSW 6.0 will support Workspace Command Interpreters (WS-CI) to allow 
more direct use control over NSW service sessions, and as support for 
providing native node tool execution, tool kits, and detachable service 
sessions. When a WS-CI is provided by a TBH, it is activated in one of 
three ways: 

o Through a designated well known name for the WS-CI entered in the 
NSW object catalog, and activated with the USE command. 

0 Through a designated NSW-wide control sequence issued while some 
other service is active. 
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0 Through the invocation of a tool kit (collection of tools to be 
run on a single host); whenever a tool kit is invoked, the user 
will find himself interacting with a WS-CI to coordinate the 
individual tool activations. 

A WS-CI will use as its prompt the host name on which it runs. All 


-Cl 

's will provide the following 

commands: 

1. 

GET (NSW-file) as (Workspace 

file) 

2. 

DELIVER (workspace file) as 

(NSW file) 

3. 

RUN (program name) 


4. 

REFUME (program name) 


5. 

KILL (program name) 


6. 

QUIT 



In addition, WS-CI's may also support standard commands of the 
following form: 

7. SHOW WORKSPACE-FILES ; to view the names of workspace files 

8. SHOW TOOLS ; to view the names of tool kit members 

9. SET file-access-mode 

10. SAVE workspace-session ;to save the workspace context for later 
resumption 

There may also be any number of host specific WS-CI commands, as well 
as interfaces to other NSW functions supported by the central NSW 
system. 

Additional parameters which are to be added to the appropriate session 
setup messages to support more sophisticated services and user 
interfaces to services: 

(a) an optional user-specified list of character strings 

collected by the FE and passed to the FM/SERVICE on startup 
(i.e. system can collect service parameters on command line; 
useful for non-TOPS-20 tools); 
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(b) full service name (character string); 

scope (region) name was found in (character string); 
user login name (character string) ; 
user session id (integer); 

NSW catalog name for workspace (character string 
when supported); 

all passed to FM as part of SERVICE startup to support the 
development of fancy tools and tool interfaces; 

(c) Begintool handling a list of augmented tool descriptors to be 
processed by a WS-CI as possible arguments to a local RUN 
command; 

(d) augment WM to FE Begintool response to support arbitrary 
cataloged ICP tools; the FE will do ICP to the host/socket 
returned form the Begintool. 

(e) Host characteristics passed to FE on service session startup; 
(static through descriptor and/or dynamic through 
communication setup Augmented FE-Open Conn to support dynamic 
setting of host characteristics regarding communication with 
the particular host/service e.g. how to handle telnet 
control options, an alarm version of WS-CI "^C" if necessary, 
etc. 


10.10 HELP MESSAGES ON THE DIRECT CONNECTION 

To allow the use of direct connections for such things as user 
confirmation of service operations, while maintaining the ability to 
alert the user to needed help for a service instance he is not 
currently using. 
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addresses 


number line 
of copies number 


Patricia Baskinger 10 

RALC/ISCP 


RADC/TSLD 1 2 

GRIFFISS AFB NY 13441 


RADC/DAP 2 3 

GRIFFISS AFB NY 13441 


ADfelNISTRATOfl 12 5 

OFF TECH INF CTR 

ATTNi DTIC-Dl)A 

CAMERON STA BG 5 

ALEXANURIA VA 22314 

HQ ESC (XPZP) 1 12 

SAN ANTONIO TX 78243 


HQ ESC/D 00 1 13 

SAN ANTONIO TX 78243 


HQ USAF/XOKT 1 17 

WASHINGTON DC 20330 


HQ USAF/HDST I 20 

WASHINGTON DC 20330 


HQ USAF/RDPV 1 21 

WASHINGTON DC 20330 


PENTAGON 108 2 

USDR&E, RM 3D-I 39 
ATTN I TSCO 
WASHINGTON DC 20301 


26 









HQ AFSC/TEVE I 29 

ANLREWS AFB MJ 20334 

HQ AFSC/CLAE I 30 

ANDREWS AFB MU 20334 

HQ AFSC/ULWA I 36 

ANDREWS AFB MU 20334 

HQ AFSC/XRKK I 37 

ANuREWS AFB MU 20334 

HO AFSC/XRKR 1 38 

ANDREWS AFB MU 20334 

HQ SAC/NRI (STINFO LIBRARY) 1 39 

OFFUTT AFB NE 68113 

AFATL/DLOUL I 44 

TECHNICAL LIBRARY 
EGLIN AFB FL 32542 

HQ 3246 TW/TETW I 46 

EGLIN AFB FL 32542 

AFATL/DLOUL 1 47 

EGLIN AFB FL 32542 

ESVC/RM (STINFO) I 48 

RATRICK AFb FL 32925 


TAFIG/IIPE 

LANGLEY AFB VA 23665 


109 


I 


50 




HQ TAC/XPS (STINFO)] 
LANGLEY AFB VA 23665 


HQ TAC/XPJC 
ATTN* Lt Taylor 
LANGLEY AFB VA 23665 


HQ TAC/DRCA 
LANGLEY AFB VA 23665 


HQ TAC/DRCG 
LANGLEY AFB VA 23665 


HQ TAC/URF 

LANGLEY AFB VA 23665 


AFSC LIAISON OFFICE 

LANGLEY RESEARCH CENTER (NASA) 

LANGLEY AFB VA 23665 


AFNL/NTYEE ( C E BAUM ) 
XIRTLAND AFB NM 87117 


AF^»'L/SUL 

ATTN* TECHNICAL LIBRARY 
KIRTLAND AFB NM 87117 


ASb/ENEGE 

ATTN* CAPT T CLELANb 
RRIGHT-PATTERSON AFB OH 45433 


ASL/ENEGE 

ATTN* MR LARRY WEAVER 
WRIGHT-PATTERSON AFB OH 454 33 





ASL/TAMC 

WRIGHT-PATTERSON AFB OH 45433 


1 


74 


ASD/XRE 1 80 

WRIGHT-PATTERSON AFB OH 45433 


A'FIT/LDE - TECHNICAL LIBRARY i 81 

BUILDING 640, AREA B 
WRIGHT-PATTERSON AFB OH 45433 

AFIT/ENE (MAJOR BORKY) 1 82 

WRTGHT-PATTERSON AFB OH 45433 


ASD/AXT 1 bd 

ATTNi CAPT CHARLES SMITH 
WRIGHT-PATTERSON AFB OH 45433 

AFHRL/OTN 1 90 

WILLIAMS AFB AZ 85224 


AFHRL/OA 1 91 

BRCXJKS AFB TX 78235 


AUL/LSE 67-342 I 96 

MAXWELL AFB AL 36112 


HQ AFCC/DAPL 1 98 

BLLG P-40 NORTH, RM 9 
SCOTT AFB IL 62225 

HQ AFCC/EPE 2 100 

SCOTT AFB IL 62225 


AFHRL/LRT 

LOWRY AFB CO 80230 


111 


1 


101 






33 CO TTW/TTGX 
KEESLER AFB MS 39534 


I 


103 


DEFENSE INTELLIGENCE AGENCY I 107 

MTN« RSE-2 (LT COL SCHWARTZ) 

WASHINGTON DC 20301 


DEFENSE INTELLIGENCY AGENCY I 108 

ATTNi RSM-I 
WASHINGTON DC 20301 


CODE RI23 TECHNICAL LIBRARY I 110 

DEFENSE COMMUNICATIONS 

ENGINEERING CENTER 

1860 WIEHLE AVENUE 

RESTON VA 22090 

DIRECTOR I Ml 

DEFENSE NUCLEAR AGENCY 
ATTN* TIL 
WASHINGION DC 20305 


CHIEF, C3 DIVISION 2 112 

DbVELOPMENT CENTER, MCUEC 
ATTNI R S HARTMAN 
GUANTICA VA 22134 


AFLMC/LGY I 116 

ATTNi major MORGAN 
GUNTER AFS AL 36114 


DIRECTOR I 119 

4V,L AjVANCED technology CENTER 

ATTNI ATC-P, CHARLES VICK 

PO BOX loOO 

HUNTSVILLE AL 35807 

EOARD/CMI 2 120 

TECHNICAL LIBRARY FL 2o78 
BOX 14 

FPO NY 09510 


Co^MANJING OFFICER I 123 

NAVAL AVIONICS CENTER 
LIBRARY - CODE 765 
INDIANAPOLIS IN 46218 


■NAVAL training EQUIPMENT CENTER 
TECHNICAL INFORMATION CENTER 
ORLANDO FL 32813 


I 


124 






COVMANOER 

NAVAL OCEAN SYSTEMS CENTER 

ATTNi TECHNICAL LIBRARY, CODE 4473B 

SAN DIEGO CA 92IS2 


SUPERINTENDENT (CODE 1424) 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 93940 


COMMANDING OFFICER 
NAVAL RESEARCH LABORATORY 
CODE 2627 

WASHINGTON DC 20375 


REDSTONE SCIENTIFIC INFORMATION CENTER 
ATTNI DRSMI-RPRD 
US ARMY MISSILE COMMAND 
REDSTONE ARSENAL AL 35809 


DOT/FAA TECHNICAL CENTER 
ARD-142 (ATTNI A R CIOFFI) 
ATUNTIC CITY NJ 08405 


NATIONAL CENTER FOR ATMOSPHERIC RESEARCH 
MESA LIBRARY 
P() BOX 3000 
BOULDER CO 80307 


AIR FORCE ELEMENT (AFELM) 
THE RAND CORP 
1700 MAIN STREET 
SANTA MONICA CA 90406 


DR RAYNER K ROSICH 
ELECTRO MAGNETIC APPLNS, INC 
C/O 7031 PIERSON STREET 
ARVADE CO 8 0004 


AEDC LIBRARY (TECH FILES) 
ARNOLD AFS TN 37389 


Director 

National Security Agency 
ATTNI TI2I3/TDL 
Fort Meade MD 20755 


Director 

National Security Agency ii3 

ATTNI WO7 

Fort Meade MD P0755 







director 

National Security Agency 

ATTN I W3I 

Fort Meade MU 20755 


Uirector 

National Security Agency 

ATTNi S254 

Fort Meade MD 20755 


Uirector 

National Security Agency 

ATTNi H()3 

Fort Meade MU 20755 


Uirector 

National Security Agency 
ATTNi RI 

Fort Meade MO 20755 


Uirector 

National Security 
ATTNi H2 

Fort Meade MU 20755 


Uirector 

National Security Agency 
ATTNi R5 

Fort Meade MO 20755 


Uirector 

National Security Agency 
ATTNi R6 

Fort Meade MU 20755 


Uirector 

National Security Agency 
ATTNi R7 

Fort Meade MU 20755 


Uirector 

National Security Agency 
ATTNI Rb 

Fort Meade MU 20755 


Uirector 

National Security Agency 
ATTNi R9 

Fort Meade MU 20755 


HQ ESU/UCF-I 
HANSCOM AFR MA 01731 


114 
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HQ ESD/FAE. STOP 27 
HANSCOM AFB MA 01731 


ESD/DCKD (STOP 53) 
ATTN I LT COMBS 
HANSCOM AFB MA 01731 


168 


HQ ESD/YSEA 
HANSCOM AFB MA 01731 


ESD/XPET 

HANSCOM AFB MA 01731 


ESD/XRWS 

HANSCOM AFB MA 01731 


ESD/XRWT 

HANSCOM AFB MA 01731 


tSD/XHWW 

HANSCOM AFB MA 01731 


ESD/XRTP 

HANSCOM AFB MA 01731 ' 


ESL/XR 

HANSCOM AFB MA 01 73 I 


ESD/DCH-3E 

HANSCOM AFB MA 01731 


185 


HQ ESU/Y:.,M iSiOP Its) 
HANSCOM AFB 01731 


H5 


2 


186 







HQ ESJ/OCR-IS 
Hanscom AFB MA 01731 


HQ ESQ/DCP-II 
HANSCOM AFB f/A 01731 


Mr. Charlie Muntz 
Mass Computer Associates 
26 Princess Street 
Wakefield MA 01880 


AFLC/LOEC 

Attn* Capt Hiski 

i^right-Patterson AFB i)H 45433 


.“^R-ALC/MMECV 

Attn* Mr. Palmer Craig 

Robins AFB GA 31098 


SM-AEC/MMECF 

Attn* Mr .Van Jonnson 

McClellan AFB CA 95652 


OC-ALC/MMECO 

Attn« Mr. Mike Parish 

Tinker AFB OK 73145 


GSG, Inc. 

Attn* Mr. uoug Payne 
51 Main Street 
Salem NH 03049 


3BN, Inc. 

Attn* Or. Rick Schantz 
50 Moulton Street 
Cambridge MA 02138 


Honeywell Information Systems 
Attn* Mr. John At a 
3Ido. 3. Room 35 








Grifflss AFB NY I344I 


UCLA 

Attn I Mr. NeU Ludlam 
Office of Academic Computinq 
Los Angeles CA 9 0024 


SRI International 
Attn* Ms. Jake Feinler 
Menlo Park CA 94025 


PAR 

Attn* Mr. Thomas MeGibbon 
Freedom Mall 
Rome NY 13440 


UNI VAC 


Attn* Mr. Paul 
PO Box 3525 


Wood 


Mail Station U2U22 
St. PAul MN 55165 


IIT Research Institute 
Attn* Ms. Lorraine Uuvall 
The Beeches Carriage Suite 
Turin Road 
Rome NY 13440 


Arlington VA 22209 






MISSION 

of 

Rome Air Development Center 

RAVC plan6 and executed nzM.an.th, deveZopmtnt, tzAt and 
6zZzttzd atquAAition pnognajM in 6uppont Oj^ Command, Contnoi 
Communications and Intzltigzncz (C^i) activUlzs. Tzchnical 
and znginzznfng suppont icithin anzas o^ tzchnicaZ compztzncz 
is pnouidzd to BSD Pnognam O^^iczs (POd) and othzn. ESP 
zizmznts. Thz pnintipai tzchnical mission anzjOLS ant 
communications, ziectnomagnzXic guidance and contAot, sun- 
vziitance of, gnound and aznospaez objects, intziligznez data 
colizction and handling, infonmation system technology, 
ionoiphznic pnopagation, solid state sciences, micnoiMve 
physics and electnonic neliability, maintainability and 
compatibility. 












